But why not do it right the first time. This is an obvious performance pitfall for people that want to adopt this feature. It is bizarre to me after the last decade has been dedicated to performance improvments.
They do this often actually. They will likely watch how people use it and tailor the design to fix that.
As for performance, in lots of use cases it's not going to be a big deal. If you are super sensitive to performance issues then you can just wait, meanwhile everyone else gets to use the new feature. You have to start somewhere and waiting to satisfy everything usually ends up with doing nothing
Allowing hallucinated content or citations into your work is an act of carelessness and disregard for the time of people that are going to read your paper and it should be policed as such.
And flatly, if a person can't be bothered to check their damn work before uploading it, why should anyone else invest their time in reading it seriously?
Why on earth did they decide boxing by default was a sensible design decision...
We have been pushing toward higher performance for years and this is a performance pitfall for unions would are often thought of as being lighter weight than inheritance hierarchies.
F# just stores a field-per-case, with the optimization that cases with the same type are unified which is still type safe.
Hi there! One of the C# language designers here, working on unions. All the different options have tradeoffs. As an example, the non-boxing options tear, which can be problematic. And, we have a lot of experience implementing the simple, reference-type, approach for types that make a lot of sense to people, but then adding a lightweight, value-type version for people who care about that later. See tuples, as well as records.
I expect the same will old here. But given the former group is multiple orders of magnitude higher than the latter, we tend to design the language in that order accordingly.
Trust me, we're very intersted in the low-overhead space as well. But it will be for more advanced users that can accept the tradeoffs involved.
And, in the meantime, we're designing it in C#15 that you can always roll the perfect implementation for your use case, and still be thought of as a union from teh language.
From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.
This is the general pattern of how the C# team operates, IME.
"Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.
In the meantime I still haven't done any project with nullable references, because the ecosystem has yet to move along. Same applies to ValueTask for async code.
Which part of the ecosystem is blocking your projects from using nullable references? I find them very helpful, but the projects were all newer or migrated to new SDK.
It is relatively easy to find corporate libraries, or commercial products that still aren't using it, including Microsoft products still stuck in .NET Framework, or .NET standard 2.0.
If you want name shaming of commercial products with modern .NET, here is one, can provide more.
You can use dependencies that aren't using nullable reference types in projects that use it. You can enable/disable nullable reference types per file, as it only influences static analysis. There's no runtime difference between a non-nullable reference type and a nullable reference type.
Active patterns, computation expressions, structural typing, statically resolved type parameters, explicit inlining, function composition, structural equality, custom operators and much richer generators.
I understand this is an attack, but I find myself mildly concerned that the model is "aware" enough to behave differently in the assumed context of a alignment test. Isn't this an inherent thread of dishonesty?
I get excited every time I see a paper from Bradish. I've learned so much about high performance software from studying systems that he has worked on. (not to diminish his many co-authors and contributors)
I’ve only played with it at scale and haven’t had the balls to do production with it. We are still heavily reliant on our k8s stack but I want to go bare metal with Orleans.
The Tree of Life is singular to me as a piece of cinema, americana and a meditation on the beauty of life and especially childhood.
When I saw it the first time, I was so awestruck by the breathtaking cinematography and the incredible music, but even more so by the vision of it all. I had simply never seen anything like it.
