C# 20: Resolving All Historical Legacy Issues

[YT-GameMaker]

Let's name the next version of C# "C#20." Through a significant version leap, we can introduce substantial disruptive changes and discard all outdated designs. If the language's development is constantly constrained by its historical legacy, it cannot truly keep up with the times, and we are forced to continue enduring those outdated designs. The best time to make changes is always "now." Building a tall structure on an unstable foundation will only become increasingly hazardous.

As for which designs are considered "outdated," that can be a topic for discussion. For example, I believe that the current method of equality comparison is outdated and should be replaced with == instead of Equals. For those structs that do not have a defined ==, default == should be generated for them, and it would recursively call == for each field, making it nested. This way, you can confidently compare any two objects of the same type, and in most cases, the default implementation should meet the requirements and offer good performance.

Another example is to introduce a new keyword, zero, representing the default state of any type. It can be used to replace null and default, unifying the syntax for reference types and value types, and providing a clearer distinction between the concepts of "uninitialized" and "new()" for value types.

Anyone who has other suggestions is welcome to share them below, aiming to make "C# 20" a comprehensive solution for all historical legacy issues in one go.

[CyrusNajmabadi]

Closing out as far too vague. Please make specific proposals on the changes you are interested in. Catch-alls of "here are all the things I want to be different" are not helpful.

Thanks!

[YT-GameMaker]

This topic is for discussing unconventional ideas that bring disruptive changes. If discussed in isolation, they are unlikely to be widely accepted, so I believe this discussion should not be closed.

[YT-GameMaker]

Alternatively, can we say that discussions about language don't need to concern themselves with engineering issues?
If that's the case, then indeed this discussion is not needed.

[CyrusNajmabadi]

Alternatively, can we say that discussions about language don't need to concern themselves with engineering issues?

That's already the case. Language ideas have to be good enough on their own merits.

If you have some you'd like discussed, please open discussions on them. Thanks!

[HaloFour]

You mistake historical design for legacy design. There are often multiple reasons why the language and runtime behave as they do. For example, it's already been noted by C# and .NET have different concepts of equality. It's not legacy, and if C# were to be redesigned it would retain that same behavior, because it is important that it behave correctly in different circumstances.

It's probably true that if the language and runtime teams had the opportunity to start all over again that they'd do some things differently. For one, it's been expressed that method overloading would likely be something they wouldn't include, due to the massive complexity it creates. But they're not going to "start again", and if they did, whatever it was wouldn't be "C#".

[theunrepentantgeek]

Through a significant version leap, we can introduce substantial disruptive changes and discard all outdated designs.

There's a mainstream language that tried this. Python.

In 2008, Python 3 was released with the intent that it would quickly supplant Python 2. This didn't happen.

Python 2.7's end-of-life was initially set for 2015, then postponed to 2020 out of concern that a large body of existing code could not easily be forward-ported to Python 3

Wikipedia

Between 2008 and 2020, the Python community had to deal with an enormous amount of pain. Library developers targeted Python 2 because of the larger community who could benefit. Application developers used Python 2 because the libraries they needed weren't Python 3 compatible. And so it went on.

There will undoubtedly come a time when a new language is introduced, taking all of the lessons of C# and its counterparts, discarding outdated features and creating a foundation for the future. However, it won't be called C#.