Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decompiling the New C# 14 field Keyword

blog.ivankahl.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Decompiling the New C# 14 field Keyword

#11

Post by estimator7292 »

twoodfin wrote: post #6

How does C# the language or C# the language standard evolution process accommodate a new keyword with such a generic name? Is it context-dependent?

It's been a while, but from memory I think C# allows you to override keywords and use them as variable names when prefixed with @

The compiler knows what you're doing. A keyword like 'field's inside a function's braces just isn't valid. Putting 'field' after a type name in a variable declaration makes as much sense as 'private int class;'

Re: Decompiling the New C# 14 field Keyword

#12

Post by materialpoint »

politelemon wrote: post #5

I can appreciate the steady syntactic sugar that c# has been introducing these past years, they never feel like an abrupt departure from the consistency throughout. I often think that this is what java could have been if it hadn't been mangled by oracle's influence, unfortunately as much I like java it's pretty obvious that different parts have been designed by disjointed committee members focused on just one thing.

This started long before Oracle and the favouring of verbose, ritualistic boiler code was set back at Sun. James Gosling has been staunchly against overloading operators, properties and value types (almost out of spite from Microsoft's success with providing this in C#), the aftermath of which the language and run-time still struggle today and forever will. It's unfortunate that the original inventor, while a brilliant programmer himself, thought so little of others that such features were not to be included, because other programmers might mess up their use.

Re: Decompiling the New C# 14 field Keyword

#13

Post by twoodfin »

janjones wrote: post #10
twoodfin wrote: post #6

How does C# the language or C# the language standard evolution process accommodate a new keyword with such a generic name? Is it context-dependent?

Yes, it's contextual. There is more details in this section of the article: Naming Conflicts with Existing Class Members

Thanks, my bad. I didn’t continue reading past the sections on Entity Framework and AutoMapper.

Re: Decompiling the New C# 14 field Keyword

#14

Post by materialpoint »

mrsmrtss wrote: post #4
Kwpolska wrote: post #3

> 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.

Agree, mapping libraries make things only more complicated and harder to debug.

Auto mappers sincerely need to go away. They work kind of fine initially, but at the first custom field mapping or nested field extraction, you have to invest hours into mostly complete failures of unecessary DSLs in order to something that is extremely trivial to do in basic C#, and often it is impossible to shoe horn the necessary mapping into place. Then you have to deal with package upgrades which regularly rewrite custom mapping logic, and to be sure you have to write additional tests just to hand hold. With multi-caret editors and regex there is no need for automappers. You can write a mapping once and forget about it.

Re: Decompiling the New C# 14 field Keyword

#15

Post by materialpoint »

drysart wrote: post #2

All 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…

Serialization is a pretty good cause.

Re: Decompiling the New C# 14 field Keyword

#16

Post by m_fayer »

Kwpolska wrote: post #3

> 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.

2025 version: write mapping functions by llm.

Re: Decompiling the New C# 14 field Keyword

#17

Post by Radle »

pwdisswordfishy wrote: post #7
drysart wrote: post #2

All 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.

The trick with using characters which by definition are not allowed inside variable names, "", should be sufficient no?

Re: Decompiling the New C# 14 field Keyword

#18

Post by rickstanley »

Kwpolska wrote: post #3

> 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.

We've been using Mapperly (https://mapperly.riok.app/), after a migration from AutoMapper, in our production application. I'm having a good experience, and we kind of like the holistic of this library.

So far, there have been no surprises, and the library warns about potential issues very explicitly, I quite like it.

Of course, if it's just a handful of fields that need mapping, than write manually is the way to go, specially if said fields require a custom mapping, where the library would not facilitate.

Re: Decompiling the New C# 14 field Keyword

#19

Post by rafaelmn »

mrsmrtss wrote: post #4
Kwpolska wrote: post #3

> 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.

Agree, mapping libraries make things only more complicated and harder to debug.

>so preoccupied with whether or not they could, they didn't stop to think if they should

This describes more than half of .net community packages and patterns. So much stuff driven by chasing "oh that's clever" high - forgetting that clever code is miserable to support in prod/maintain. Even when it's your code, but when it's third party libs - it's just asking for weekend debugging sessions and all nighters 2 months past initial delivery date. At some point you just get too old for that shit.

Re: Decompiling the New C# 14 field Keyword

#20

Post by NetMageSCW »

materialpoint wrote: post #15
drysart wrote: post #2

All 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…

Serialization is a pretty good cause.

Serialization shouldn’t be dependent on the name of the backing field.
Post reply on HN