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

71–80 of 100 posts

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

#71

Post by gizmo »

jddj wrote: post #59
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.

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…

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

Thinking those are the only options is exactly why the issue is expressiveness.

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

#72

Post by tryfinally »

nick_ wrote: post #55

The inline array feature is good, but the implementation is very bad. Why would we need to make a struct with an attribute and a weird member?

It’s an extraordinary feature that is only intended for optimization of edge cases. Making the feature verbose and somewhat ugly to use seems like an intentional choice. This way if a beginner comes across this “confusing/weird looking” code they can look up the attribute and see what it does, whereas a more convenient/native syntax would be less recognizable and noticeable. This is similar to the idea that you should make ugly APIs ugly to use (to avoid giving users a false sense of security).

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

#73

Post by pjc50 »

gizmo wrote: post #71
jddj wrote: post #59

Earlier quoted context omitted.

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…

> 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. Thinking those are the only options is exactly why the issue is expressiveness.

Is this a reference to some specific, better, technique or an optimistic belief that such a thing could be built if only ..?

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

#74

Post by alkonaut »

jve wrote: post #66
alkonaut wrote: post #60

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.

Discriminated Unions will make working with Result easier as would provide exhaustive checking. DUs are being designed: https://github.com/dotnet/csharplang/issues/113

Fantastic. I note it's indeed being designed since 2017 so it's probably not as easy as I would hope. The design seems to not have progressed beyond discussion at all in 6 years.

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

#76

Post by nick_ »

tryfinally wrote: post #72
nick_ wrote: post #55

The inline array feature is good, but the implementation is very bad. Why would we need to make a struct with an attribute and a weird member?

It’s an extraordinary feature that is only intended for optimization of edge cases. Making the feature verbose and somewhat ugly to use seems like an intentional choice. This way if a beginner comes across this “confusing/weird looking” code they can look up the attribute and see what it does, whereas a more convenient/native syntax would be less recognizable and noticeable. This is similar to the idea that you shoul…

But we can already do `Span ints = stackalloc int[5];` without using `unsafe`. The array size doesn't even have to be const in that example. They could have just made an optimization when a const is supplied for locals, and then use the existing fixed array syntax for members.

It seems to me the budget for C# lang dev is way down. This seems like it was implemented this way so they didn't have to change many internals.

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

#77

Post by gizmo »

pjc50 wrote: post #73
gizmo wrote: post #71

Earlier quoted context omitted.

> 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. Thinking those are the only options is exactly why the issue is expressiveness.

Is this a reference to some specific, better, technique or an optimistic belief that such a thing could be built if only ..?

Code generators are used because run-time introspection tends to be slow(er) and because debugging code generated at runtime is harder and because IDEs don't know how to deal with code generated at runtime. But there no reason why this should be so. No good reason to have a hard boundary between compiletime and runtime either. These are just historical artifacts.

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

#78

Post by mpawelski »

zmj wrote: post #41

Collection expressions are somewhere between spooky and very cool. If you don't specify a concrete type for the collection, the compiler is free to choose the "best" option given your usage of the collection: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

You must specify concrete type.

There was a plan to have "natural type" so "var list = [1,2,3]" would be of type "List" but it was postponed to C# 13 (https://github.com/dotnet/csharplang/issues/5354#issuecommen...)

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

#79

Post by Kuinox »

pjc50 wrote: post #65
Kuinox wrote: post #30

Earlier quoted context omitted.

C# preprocessor and code generator have nothing to do with JS build chains. The .NET build chain is relatively painless.

People very rarely rely on extra source code generation stages or preprocessors in C#. The Javascript ecosystem is dependent on them because Javascript is the only language that's a first class citizen in the browser. You can also do some pretty expressive things in C# with LINQ, expression trees, reflection, and so on. You can even emit IL at runtime if you really need to. https://learn.microsoft.com/en-us/dotnet/cs…

> You can even emit IL at runtime if you really need to.

I know, I already did that (generating mapping to industrial controllers from the config).

> The only C# generator I'm familiar with is for protobuf.

If you use .NET 6 you may use multiple source generator without knowing, it's very transparent.

For example, if you use System.Text.Json you may be using code generation.

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

#80

Post by jk_i_am_a_robot »

tight-ship wrote: post #17
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.

C# has always been pretty good about evolving the language. Java has recently left the freezer and seems to be catching up as well. I don't use Java but I see people excited about new releases since v11 or so.

C# designers have always made good choices about syntactic additions. Contrast this to modern C++ designers who jam in every new addition with the goal of total inscrutability.
Post reply on HN