▲ | maltalex 5 days ago | ||||||||||||||||||||||||||||||||||||||||
Cute, but is this actually needed? It's one more thing to remember, one more thing to know the subtleties of, and for what? To save writing a very readable and unambiguous line of code? It feels like the C# designers have a hard time saying "no" to ideas coming their way. It's one of my biggest annoyances with this otherwise nice language. At this point, C# has over 120 keywords (incl. contextual ones) [0]. This is almost twice as much as Java (68) [1], and 5 times as much as Go (25) [2]. And for what? We're trading brevity for complexity. [0]: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... keywords/ | |||||||||||||||||||||||||||||||||||||||||
▲ | Metasyntactic 5 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||||||||
> Cute, but is this actually needed? It's one more thing to remember, one more thing to know the subtleties of, and for what? Hi there! C# language designer here :-) In this case, it's more that this feature made the language more uniform. We've had `?.` for more than 10 years now, and it worked properly for most expressions except assignment. During that time we got a large amount of feedback from users asking for this, and we commonly ran into it ourselves. At a language and impl level, these were both very easy to add in, so this was a low cost Qol feature that just made things nicer and more consistent. > It feels like the C# designers have a hard time saying "no" to ideas coming their way. We say no to more than 99% of requests. > We're trading brevity for complexity There's no new keyword here. And this makes usage and processing of `?.` more uniform and consistent. Imo, that is a good thing. You have less complexity that way. | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
▲ | ygra 5 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
I stumbled over this a few times, mostly when cleaning up older code. This basically just means that using the ?. member access no longer dictates what is possible on the right side. Property reads were fine before (returning null if a part of the chain was null), method invocations were fine (either returning null or just being a no-op if a part of the chain was null). But assignments were not, despite syntactically every ?. being basically an if statement, preventing the right side from executing if the left side is null (yes, that includes side-effects from nested expressions, like arguments to invocations). So this is not exactly a new feature, it just removes a gotcha from an old one and ensures we can use ?. in more places where it previously may have been useful, but could not be used legally due to syntax reasons. | |||||||||||||||||||||||||||||||||||||||||
▲ | zigzag312 4 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
I don't get this argument as it really doesn't match my practical experience. Using new C# features, the code I write is both easier to read and easier to write. On top of that it's less error prone. C# is also much more flexible than languages you compared it to. In bunch of scenarios where you would need to add a second language to the stack, you could with C# still use just one language, which reduces complexity significantly. | |||||||||||||||||||||||||||||||||||||||||
▲ | buybackoff 5 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
> is this actually needed Yes, actually. I did write it multiple times naturally only to realize it was not supported yet. The pattern is very intuitive. | |||||||||||||||||||||||||||||||||||||||||
▲ | alkonaut 5 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
Yes, this doesn't actually add anything to the "size" of the language, if anything it actually shrinks it. It's existing syntax (the ? and ?? operators) and existing semantics. The only thing was that it worked in half the cases, only reads but not writes. Now this completes the functionality so it works everywhere. You can argue that C# gets a lot of new features that are hard to keep up with, but I wouldn't agree this is one of them. This actually _reduces_ the "mental size" of C#. | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
▲ | bob1029 5 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
Nothing is stopping you from constraining the language version you want to be used in your projects: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... You can force it all the way down to ISO-1/2. If this is still insufficient, then I question what your goals actually are. Other people using newer versions of C# on their projects shouldn't be a concern of yours. | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
▲ | pjmlp 5 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
Agreed, it appears that since they changed to early release their have become pressured to add new language features every year. As polyglot I have the advantage that I don't have to sell myself as XYZ Developer, and increasingly I don't think C# (the language itself) is going into the direction that I would like, for that complexity I rather keep using C++. Just wait for when extension everything, plus whatever design union types/ADT end up having, and then what, are they going to add on top to justify the team size, and yearly releases? Despite my opinion on Go's design, I think the .NET team should take a lesson out of them, and focus on improving the AOT story, runtime performance, and leave the language alone, other than when needed to support those points. Also bring VB, F# and C++/CLI along, this doesn't not have to be C# Language Runtime, where it gets all the features of what designed as a polyglot VM. | |||||||||||||||||||||||||||||||||||||||||
▲ | johnh-hn 4 days ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
I went to the .NET Developer Conference (NDC) in London at the beginning of the year. Mads Torgersen (Lead C# Designer, for anyone not in the know) gave a talk about some new proposed features. After describing a proposal to introduce new syntax to make defining extension methods easier, he asked if anyone had any questions. I asked a question along the lines of: "I understand we sometimes need to address deficiencies in a language, but when we do stop? More syntax is leading to daily decision fatigue where it's difficult to justify one approach over another. I don't want C# to become C++." It was interesting listening to the discussion that took over from that. The audience seemed in favour of what I said, and someone else in the audience proposed a rolling cut-off to deprecate older features after X years. It sounded very much like Mads had that discussion internally, but Microsoft weren't in favour. I understand why, but the increasing complexity of the language isn't going to help any of us long-term. | |||||||||||||||||||||||||||||||||||||||||
▲ | ochronus 5 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||||||||
Life quality upgrade - needed? Depends. |