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

What's new in C# 12: overview

pvs-studio.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: What's new in C# 12: overview

#51

Post by throw1234651234 »

vsareto wrote: post #50
throw1234651234 wrote: post #46

Earlier quoted context omitted.

It's more for DI than tests, really, right? Still, I have very rarely found it practical.

They're not required for MS's dependency injection, not sure about other libraries. 95% of the interfaces I've ever seen used for DI only have one implementation, and that 5% is generous. This makes maintaining the class and the interface tedious. The reason this is so common is probably because code examples (including MS) often have it, so it gets followed the first time and repeated.

Absolutely my experience is well, I have been writing .NET for over a decade, and I think I have seen a handful of cases mainly when we were bored or when I remembered the Interface Segregation principle and tried to shoehorn it into code (though the principle does work well to have methods take the minimum number of props needed to do their job, but that's a whole other topic).

Re: What's new in C# 12: overview

#53

Post by vsareto »

genter wrote: post #12

Not sure if I like primary constructors. TBH, the following feature of Dart that I like: class Point { public Point(this x, this y); int x; int y } Everything else seems like small quality of life improvements. And still patiently waiting for the following to be legal: int result = some_variable switch { a => callAFunctionReturningVoid(); 1, b => 2, };

Just IMO but that line does too much and deserves a regular switch due to the function call. It's too compressed for readability.

Re: What's new in C# 12: overview

#54

Post by tonyedgecombe »

jjice wrote: post #14

I love that Java and C# (not sure about VB.NET and F# in the .NET ecosystem) are continuing to get handy language features instead of collecting dust. The array syntax stuff is a nice win. Having other languages be the guinea pigs for language features is a good way to go.

They seem to have picked most of the low hanging fruit though. Most of this is nice to have but not earth shattering.

The only feature I've been hoping for is abstract data types. I'm not sure how they could make them work in .Net though. Presumably F# has crossed that hurdle.

Re: What's new in C# 12: overview

#56

Post by jbluepolarbear »

gizmo wrote: post #47
ToruiDev wrote: post #42

Earlier quoted context omitted.

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't think this is too valid of a concern.

Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.

So how would you solve the AOT (ahead of time compiling) problem without code generation? An entire ecosystem (Unity) that uses C# requires that code must be AOT for supporting IL2CPP (a low level translation of IL to c++). Dynamics and Reflection of non-AOT types are unavailable at runtime. IL2CPP came from Apples requirement that no JIT be run in apps and to get more performance; especially, for features like burst that allows writing C# that directly translates to high performance multithreaded c++.

Re: What's new in C# 12: overview

#57

Post by pjc50 »

gizmo wrote: post #47
ToruiDev wrote: post #42

Earlier quoted context omitted.

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't think this is too valid of a concern.

Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.

You can't make a language fully general without it turning into a mess; things like the protobuf compiler are reasonable use cases for source generation.

Re: What's new in C# 12: overview

#58

Post by pjc50 »

jbluepolarbear wrote: post #56
gizmo wrote: post #47

Earlier quoted context omitted.

Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.

So how would you solve the AOT (ahead of time compiling) problem without code generation? An entire ecosystem (Unity) that uses C# requires that code must be AOT for supporting IL2CPP (a low level translation of IL to c++). Dynamics and Reflection of non-AOT types are unavailable at runtime. IL2CPP came from Apples requirement that no JIT be run in apps and to get more performance; especially, for features like burst…

Different usage, I think: if people are talking about "language not expressive enough", they're referring to mechanisms for generating C#, or IL, not things further down the toolchain for AOT.

System.Xml.Serialization, for example, relies on generating assemblies at runtime to work. That's "code generation", but of a kind that directly conflicts with the AOT meaning of "code generation".

Re: What's new in C# 12: overview

#59

Post by jddj »

gizmo wrote: post #47
ToruiDev wrote: post #42

Earlier quoted context omitted.

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't think this is too valid of a concern.

Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.

That's not really true.

Source generation is used at some level to implement expressivity at minimal runtime cost. It's just operating at a different level of abstraction to make different tradeoffs.

Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness.

If you design around a Foo does it matter if behind the scenes it generates a FooOfBar?

Should a language inherently care specifically about protobufs, flatbuffers, capnproto, etc because expressiveness or should it just have capable source generators for building strongly typed interfaces without the legwork? Are you sure an alternative implementation which is more expressive would be better or would it just be different?

Re: What's new in C# 12: overview

#60

Post by alkonaut »

I welcome these but for each of 8, 9, 10, 11 and 12 I still feel that the elphant (missing) in the room is a proper sum type. How come I have to write some 100 line monstrosity of a utility class each time i want "Either a result or an error" or similar.
Post reply on HN