Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But that's .NET, not C#. Language and platforms are different. Libraries must be compatible (because you don't know if your library will be consumed in a newer app).

But the compiler only consumes syntax (C#11, C#12 C#13 and so on) so I don't see why the compiler that eats C#13 necessarily must swallow C#5 without modification



They did a breaking change in a recent C# where nullable objects must be postfixed with a ?, so old code is:

  public Patient Patient { get; set; }
The same thing with modern code would be

  public Patient? Patient { get; set; }
Because with the new C#, objects are by default not null. Fortunately there is a compiler flag to turn this off, but it's on by default.

As a guy who has worked in C# since 2005, a breaking change would make me pretty irate. Backwards compatibility has its benefits.

What issues do you have with backwards compatibility?


NRT wasn't really breaking as it's a warning which you control top level. But there have been some real breaking changes in edge cases but they are pretty far between. I think the language could be better if it was always structured in the best way possible, rather than in the best compatible way.

As a class library example (which is contrary to what I said earlier about .NET compatibility vs C# compatibility) is that it was a massive mistake to let double.ToString() use the current culture rather than the invariant culture. It should change to either required passing a culture always (breaking API change) or change to use invariantculture (behaviour change requiring code changes to keep old behavior)


>a massive mistake to let double.ToString() use the current culture rather than the invariant culture.

I would imagine that's a carryover from the Win32/Client-Server days when that would have been a better choice.

Is that annoying? Yea. Is that annoying enough to force companies to collectively spend billions to look through their decades old codebases for double.ToString() and add culture arguments? Also keep in mind, this is a runtime issue, so the time to fix would be much more than if it were a compile issue. I would say no.


Nowadays you just apply https://learn.microsoft.com/en-us/dotnet/core/runtime-config... and call it a day. It is also added as a default to all AOT templates.


That's a great idea (and after the fact, much better than changing the API). On day 1 it should have been easy though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: