I feel like in a few more years and 2-3 major versions C# will have all the useful features of F#.
It will also keep being much more exciting because our benevolent corporate visionaries manage to add new gotchas with every major and some minor releases
Decompiling the New C# 14 field Keyword
21–30 of 37 posts
Re: Decompiling the New C# 14 field Keyword
#22> If you want to avoid this issue altogether, consider using a source generator library like Mapster. That way, mapping issues can be caught at build time rather than at runtime. The only winning move is not to play. Mapping libraries, even with source generators, produce lots of bugs and surprising behavior. Just write mappers by hand.
Every time I've worked on a project that used AutoMapper, I've hated it. But I'll admit that when you read why it was created, it actually makes sense: https://www.jimmybogard.com/automappers-design-philosophy/
It was meant to enforce a convention. Not to avoid the tedium of writing mapping code by hand (although that is another result).
Re: Decompiling the New C# 14 field Keyword
#23All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name". In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is re…
I'm surprised there isn't something pseudorandom thrown in for good measure – like a few digits of a hash of the source file.
I believe the reason for this is that it would break deterministic builds.
Re: Decompiling the New C# 14 field Keyword
#24How does C# the language or C# the language standard evolution process accommodate a new keyword with such a generic name? Is it context-dependent?
Historically every time new keywords are added, they try to make them contextual so that existing code won't break. 'await' and 'yield' are both examples where a new keyword was added without (generally) breaking existing code - they're only keywords in specific contexts and the way you use them ensures that existing code won't parse ambiguously, AFAIK.
Re: Decompiling the New C# 14 field Keyword
#25Earlier quoted context omitted.
I'm surprised there isn't something pseudorandom thrown in for good measure – like a few digits of a hash of the source file.
I believe the reason for this is that it would break deterministic builds.
dotnet build is’t deterministic as default. Never has been.
Re: Decompiling the New C# 14 field Keyword
#26TL;DR nothing surprising, it's just syntactical sugar.
Re: Decompiling the New C# 14 field Keyword
#27Re: Decompiling the New C# 14 field Keyword
#28I always shy away from syntax sugars. If I like a private field with setter and getter I write it into my code. The most of the code is written by autocomplete and if I do now like to se it I just fold it away. I have control over the naming and I can set breakpoints into the getter/setter to trap all those case where I somehow write rubbish. I also have the benefit of seeing the field in my debugger and can access them for hydration without the setter. I see no real use in such new keywords. Just my 2 cents
Re: Decompiling the New C# 14 field Keyword
#29I always shy away from syntax sugars. If I like a private field with setter and getter I write it into my code. The most of the code is written by autocomplete and if I do now like to se it I just fold it away. I have control over the naming and I can set breakpoints into the getter/setter to trap all those case where I somehow write rubbish. I also have the benefit of seeing the field in my debugger and can access t…
> I can set breakpoints into the getter/setter
field doesn't stop this.
> I also have the benefit of seeing the field in my debugger
The debugger could still show it. The backing field is still there.
Re: Decompiling the New C# 14 field Keyword
#30Earlier quoted context omitted.
Serialization is a pretty good cause.
Serialization shouldn’t be dependent on the name of the backing field.
You are conflating awkward auto-generated backing fields with plain backing fields. A proper serializer handles these cases.
Yes, serialization should and must depend on names, how else to put things back together? The onus is always on the programmer to not break serialization, or provide migration.