Add set of compiler options instead of introducing breaking changes/wierd syntaxes.

[MkazemAkhgary]

There are some features that would be nice-to-have, how ever there are mainly two problems that these features are postponed

1. backward compatibility problem.
2. added complexity of language for new syntax

Some people tend to use new features, some people don't. not because they don't like it, mostly because they don't want to face with their large code base again.

the obvious solution is to not go forward, stay back and use older version of C# language. but that prevents developer to use other new features that does not conflict.

I would like Roslyn team, (if they decided to add some of these) instead of putting them as pile of options in Build page, put them in category. (something like Semantic Analysis Options.)

Here is list of compiler options that can be activated manually (to support breaking change features)

---

- discards all over. #1064

an option to let compiler know, if it should treat underbar solely for discards or not.

- infer generic arguments from generic types. #1018, #997, #478, #741, dotnet/roslyn#5023, dotnet/roslyn#15166.

an option to let compiler use improved rules for inferring generic types.

---

if you have other good options in mind, comment below with convincing reason in order to make this list completed. (ill keep updating this with mentioning who suggested what option.)

[yaakov-h]

dotnet/roslyn#1580

[iam3yal]

@MkazemAkhgary I hate (not using this word often but I really dislike) having options that change the meaning of the code, I like code that reads one way and I prefer to have a deprecation strategy where first warnings are given and then at some point in the future they turn into errors, depends on the kind of breaking change and telemetry the language team can decide what's the best major release to change these warning into errors.

[MkazemAkhgary]

@eyalsk

There is already unchecked/checked behavior that can change in compiler settings. although that solely affects runtime, but it can change behavior of program anyway.

Try to look in wider perspective, its not only us (yes me and you 😸) who want these features, think about problems that it can arise for others.

with compiler option all you have to do is to enable this option. (or maybe in newer versions have these enabled by default so you are really good to go)

all developers with older source code, have to do is to disable those options.

That's it, with simple option let them live in separate universe. whats wrong about that? this proposal solves backward compatibility problem, also prevents inventing weird syntaxes.

Note that each options I suggest are mutually exclusive, that means, while coding you go either way. so its not like I want this behavior On here, and Off there.

[MkazemAkhgary]

@eyalsk I see that deprecation strategy works too, for _ specifically. but what about generic type inference?

[iam3yal]

@MkazemAkhgary

There is already unchecked/checked behavior that can change in compiler settings. although that solely affects runtime, but it can change behavior of program anyway.

Yup and I'm not in favor of more of them unless it's really justified and in this case it is.

I see that deprecation strategy works too, for _ specifically. but what about generic type inference?

Saying generic type inference without a link to the proposal doesn't help much so I can't make any comments on it. :)

[MkazemAkhgary]

@eyalsk here you go :) #997 (comment)

[HaloFour]

The team has stated a preference for not creating different dialects of the C# language based on compiler options. Whatever features are involved would have to exceed a very high bar. Other than non-nullable reference types I don't see it happening elsewhere in the language.