Plan and break big in C# 10

[gulshan]

Version 10 for anything looks significant. As C# 7 has not been released yet, there is still 6+ years left before C# 10. I propose to make C# a greatest modern language ever in version 10, and to serve the purpose, break big. And start planning for this from now onward, so that everybody can be ready for this, when it happens.

[HaloFour]

Break what? And why?

[gulshan]

Once Eric Lippert some, what could have been done better in C#-
http://www.informit.com/articles/article.aspx?p=2425867
Things like that.

[alrz]

If every version of C# is required to be compatible with the prior version, 8 will be compatible with 7, 9 will be compatible with 8, and 10 will be compatible with 9, therefore, 10 will be compatible with 7. that's a transitivity relation right there. So there wouldn't be breaking changes as in breaking things even in C# 10. Although, it's possible to relax/restrict some of the rules with warning waves (#1580) in an opt-in manner. In fact, if a breaking change is reasonable enough to take, it's almost always preferable to do it sooner than later, because with every release. more code will depend on the possibly unwanted behavior. Also, analyzers could address most of those today so you don't need to wait until C# 10 to not shoot yourself in the foot.

[HaloFour]

Most of those specific "mistakes" are minor and can be easily avoided. You could even render them illegal via analyzers. Removing those from C# wouldn't make it any more modern of a language.

Some are just stylistic preferences. I personally prefer : over implements/extends and don't find Java easier to read.

[MgSam]

#MakeCSharpGreatAgain

[HaloFour]

I think that instead of setting up some arbitrary deadline/version through which portions of the language will be broken that it would be more useful to have a documented timeline through which specific proposals are introduced and enforced. For example, say anonymous delegates are to go the way of the dodo, the designers could say that in C# 8.0 using an anonymous delegate would result in a warning wave in strict mode, then in C# 9.0 it could result in a warning in all modes and finally in C# 10.0 it would be an error unless you explicitly selected a previous language version. The IDE could assist in guiding developers through these migrations by offering quick fixes to replacement syntax as well as defaulting the language version when opening with a newer IDE if such features are detected.

That's assuming that such changes would be considered at all. It doesn't really cost the C# team anything to leave anonymous delegates in the language, but it would cost time and effort to plan for and implement their demise, and in the end the developer isn't really any better off. But with a framework each specific proposal could be considered independently and implemented in due time.

[iam3yal]

@HaloFour

I think that instead of setting up some arbitrary deadline/version

But 10 is the new 1.0. 😉

[alrz]

say anonymous delegates are to go the way of the dodo

I don't think that's an option. Once something makes its way to the language it becomes a style and people are pretty strict in that regard. I think it just should be a code style option to prefer lambda if applicable*.

*Note that anonymous delegates are capable of ommiting all parameters (even without wildcards).

That's assuming that such changes would be considered at all.

Swift, for example, did remove C-style for loops and increment / decrement operators but it also has ranges which cover most common use cases. I don't think anything like that has ever been considered for C#. It is interesting to read Swift proposals on the matter, but in my opinion they are not completely applicable to C#. Besides, since C# is compiled to IL and the team is reluctant to do optimizations in the front-end (#15644 (comment)), such constructs sometimes are actually preferable for performance reasons. A documented timeline wouldn't work either because considering 16 years of C# code even .NET itself probably could not afford such changes.

I re-read the article and noticed that some of them are not directly related to C# itself, rather, they are actually more related to the fundamental design of BCL. For example, equality; of course analyzers could help to generate the boilerplate but it certainly does not remove the bloat from the code. Another example of this is IEnumerable interface which is known to have room for improvements, but it would not be possible to do it as a non-breaking change or just yet another standard. Perhaps other features like "extension everything" and "default interface methods", etc could help to do a better job in this space.

Other points like empty statement, as mentioned in the article, has actual use cases even in modern code (for example, Roslyn codebase, if you will). So the best thing to do is to leave it as-is and warn in obvious cases that are known to be likely unintended, like in while loops.

PS: I'm not completely in disagreement with the points mentioned though, for example No. 1 and 6.

[HaloFour]

@alrz

I don't think that's an option. Once something makes its way to the language it becomes a style and people are pretty strict in that regard. I think it just should be a code style option to prefer lambda if applicable*.

I fully agree, just using it as an example. Probably not a particularly good one given that the anonymous delegate syntax, while considered a mistake in hindsight, is pretty innocuous.

A better example might be retiring _ as a legal identifier, which is something that Java is currently undergoing (warning in 8, will be an error in 9). Considering the double-duty that _ is doing in C# 7.0 I think it could be argued that C# should follow suit.

Either way, my only argument is that any and all arguments to "break" existing language should be considered individually and implemented under a standard timeline, not crammed into some single arbitrary release.

[iam3yal]

@HaloFour

A better example might be retiring _ as a legal identifier

You mean hypothetically when it's not followed by another valid identifier, right? or completely ditch it? because some people would hate if their fields would no longer be prefixed with an underscore.

Edit: Okay.. they actually ditched it, that's wow... okay I can't even put it into words but let's just say that if this change will make it into C# I don't even know how would I react to that simply because I like to prefix all my fields with an underscore.

[HaloFour]

@eyalsk

I mean as a standalone identifier name. You can still use it as a prefix in an identifier:

int _foo = 123; // fine
int _ = 123; // warning
Consumer<Integer> consumer = _ => { };  // error

[iam3yal]

@HaloFour Yeah, that's sensible.

[vbcodec]

yes we can !!!

[vbcodec]

@HaloFour

__ still valid ? :)

[HaloFour]

@vbcodec

Yes. The changes to Java only affect fields/variables specifically named _.

[gulshan]

Actually I can think of some more fundamental features, which are mostly impossible without hard breaking changes. Most of them are functional language constructs-

• void as a real type aka unit type. Suggestion: void as a first-class citizen #234 0 - Backlog
• Everything is an expression. Lazy evaluation. Partially- Features need to be reviewed for interaction with expression-bodied everything #14351 2.0 (RTM)
• Correcting the billion dollar null mistake. Posed for v.next. But to enforce, error instead of warning is needed. New Language Feature - Nullable Reference Types Nullable Reference Types 3.0
• Data is immutable by default. Similar- #159 0 - Backlog Proposal: Immutable Objects #7626
• Functions are pure by default. Similar- C# Pure Function Keyword to Mark No Side Effects Or External Dependencies #7561
• Getting rid of non-generic data structures from netstandard. (depends on void/unit type)
• Partial application of functions. And higher order functions. And method chaining. Partial function application and function chaining #3171 Proposal: Forward Pipe Operator #5445 2 - Ready
• More type inference for lambdas. Define a default delegate type of Action/Func from method group or lambda #3990 (comment)
• Using utf8 by default for texts. etc.

The C# can make much wiser decision regarding what to do, given they can break. My proposal to start planning now means the constituting the "legal -> styling error -> warning -> error" route or other measures for easy transition.

[HaloFour]

@gulshan

For the most part it's called F# and it already exists. C# is not going to become F#. C# may implement some small subset of those requests eventually, but only those that fit within the expectations of C#.

[gulshan]

@HaloFour Almost all of these are suggested in one way or other. I have updated my list with references. And you know those very well, as you have participated in all of those discussions. Many are barred just because it is a breaking change. So, if we plan beforehand to break at some time in future, there is a lot which can be done.

[iam3yal]

@gulshan I made a joke above about 10 being the new 1.0 but really I think that if the C# team had a migration path from one version to another and a tool that would fix the code reliably then maybe they could use this to fix some of the decisions that were made in the past. (such a tool was discussed somewhere...)

Another issue is some people are using 3rd-part libraries so they might have to replace these libraries and maybe some of them are no longer maintained.

I have a friend that in his company they are still using ASP.NET WebForms on .NET 4.0 and I wrote a component for them using C# 2.0 that I'm not going to rewrite or touch ever and they probably wouldn't replace it unless they will rewrite everything so there's these sort of issues, now, I'm not sure if they are using the latest C# there so maybe it wouldn't be a problem for them at all but for some companies it might.

Personally, I want to see arrays covariance, null reference types fixed and immutable types introduced as proposed here #159 and finally type inference for generics and lambdas.

[gulshan]

I agree that, there should be no breakage in IL level. Meaning all libraries/assemblies compiled with any previous version of C# should keep working. And if a 3rd party/not maintained code is being compiled, they should be able to opt out of new warnings and error by mentioning the level of warning/error it is happy with. This will be enabled by the Warning Wave.

[gafter]

I like this idea of breaking big. Lets change the syntax to the VB syntax. </sarcasm>

[jaredpar]

Closing as this is not the road the C# team is considering. Back compat is one of our most important features and one we take great pains to maintain between releases.