Tentative C# 12 feature list #69074
Replies: 14 comments 87 replies
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
|
InlineArrays are - I'm assuming - useful, but I don't see how it's a C# feature. Similarly to Interceptors; how are they C# features? All their functionality comes from Attributes. They're - to me - clearly ".Net 8 features". Primary constructors, nameof, using, lambda, and collection(expressions? Why the rename? Is it because it's not constant? Never seen anything mentioned on it before now) are all clearly changes to C#, but the addition of an Attribute counts as a change to the language? That's quite extreme in my book. |
Beta Was this translation helpful? Give feedback.
-
Because they have to be understood by the language and compiler in order to make code legal.
We are uncertain where interceptors will land. Different stages of the proposal have involved language changes or not. Right now we're experimenting with them solely as a compiler feature. But we've had requests, and we may learn through our own previews, about things that would pull it back to being a lang feature.
Correct. More specifically, that it is not immutable. Conversations with several different sources showed confusion over this point. Where people stated that their intuition around this feature was that it produced immutable collections only, due to the name 'literal' being in it. We also wanted to match this with 'tuple expressions', a feature we view as a spiritual sibling to this one. Naming things consistently between the two is nicer. This also applies to the implementation, which we want to match in naming to the feature, and which we want to match in naming to the many existing features that have already shipped. |
Beta Was this translation helpful? Give feedback.
-
|
@sgf Please keep feedback constructive and professional. For more info, see the .Net code of conduct: https://dotnetfoundation.org/about/policies/code-of-conduct Note: if you're unhappy with the rate of feature releases, we welcome community contributions. Several community members have been very involved with the last few releases of C#, working with the team to help on creating good specifications, and on the implementation side of things. |
Beta Was this translation helpful? Give feedback.
-
|
Cut of field keyword is huge disappointment for me. Was there a real consideration in the decision making, if that feature will not be published as it is, without waiting for something, that has uncertain complexity? I mean, that feature is so long awaited, many times suspended and workaround for that feels so ... unnatural. I remember when started using C#, I was so confused, why auto-props work by default, but when wanting to implement non-default accessors, it has to declare dummy backing field... |
Beta Was this translation helpful? Give feedback.
-
|
We've gone 6 releases without this. Spending a few extra months to get it right is certainly much better for the long term health of the language :)
It could be. But then would have to likely be revised very soon afterwards, which risks confusion of its own. We'd rather just ship it in the state we want it to be in for the future of the lang. |
Beta Was this translation helpful? Give feedback.
-
|
c# 12 without 'field' is such a waste of .net LTS release, let's wait for .net10 then... |
Beta Was this translation helpful? Give feedback.
-
|
How hard/time consuming will be to add that feature in some non-recommended experimental mode, for same smaller hobbyists/prototypers/small, non-industry codebases? Especially when that feature is almost done (if I understand correctly) and has also working branch on SharpLab online compiler... (not sure how complete it actually is) |
Beta Was this translation helpful? Give feedback.
-
|
All this is possible. This is open source, so if you want to play, you can :-) |
Beta Was this translation helpful? Give feedback.
-
The feature is definitely not almost done. The code is very very very much just in the initial state. |
Beta Was this translation helpful? Give feedback.
-
|
Decent list of changes, but I am still disappointed to see that partial properties was once again not even included in the initial plan. This is also surprising when .NET is still huge for client-side applications. And partial properties would make declaring INPC and dependency properties much closer to how it looks in popular JS frameworks. An auto property with an attribute. "field" keyword would only slightly improve this problem. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
It can't be overstated how useful partial properties will be for INPC and source generators. Almost all .NET UI frameworks will take advantage of this to some degree and it will simplify a lot. MVVM toolkits (not as widely used I know) will also be significantly improved by what this allows. |
Beta Was this translation helpful? Give feedback.
-
Regarding inline Arrays, the compile-time fixed length means that when you need to define inline arrays of different lengths, you need different types. This is really ridiculous.
|
Beta Was this translation helpful? Give feedback.
-
|
Inline arrays are meant purely for perf so this particular inconvenience is somewhat expected. They are NOT reference types which means u can avoid allocation(s). That being said im also somewhat disappointed in this feature but for different reasons eg. C++ also has something like that although more neatly done and they have anonymous iniline arrays which we dont (eg |
Beta Was this translation helpful? Give feedback.
-
|
The fixed-size buffer
This would be perfect. |
Beta Was this translation helpful? Give feedback.
-
|
Fixed size buffer also requires special handled struct generated by compiler: |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion, there is no difference. Even the principle is the same. Obviously fixed size buffer is almost a more automated InLineArray |
Beta Was this translation helpful? Give feedback.
-
|
Roll up, roll up. It's LTS release time, folks. Let's see what C# has on offer this time around ... Oh! Well that was a little disappointing: Oh well, not to worry. C# 14 will be along in two years... 🙄 |
Beta Was this translation helpful? Give feedback.
-
Some features are tied to the runtime, yes. But a lot of features are syntactic sugar that can be used without problem. Of course you have to make sure you have a good automated test set that you can run to verify the correct working of your application. |
Beta Was this translation helpful? Give feedback.
-
This is absolutely not the case. Even at our last conference, with thousands of participants from an enormous variety of domains, we saw an incredible amount of trepidation from users about breaking compat. |
Beta Was this translation helpful? Give feedback.
-
Microsoft's official line is that only the current .NET version is supported with each language release. The .NET version determines the language version and the advice from MS is to not change that. Sure, you can override that, but if your company takes software security seriously, that likely won't be permitted.
Your CTO might be happy for you to spend company time and money testing C# versions on unsupported platforms. A great many won't be. |
Beta Was this translation helpful? Give feedback.
-
|
@DavidArno As a partner and developer lead at a small company, I'm happy for our devs to invest time into anything they think might improve our day-to-day coding, even if it doesn't ultimately pan out. For this particular example, there are so many benefits to using newer versions of C# on older platforms, and as a whole, we have not found this to cost much. |
Beta Was this translation helpful? Give feedback.
-
We all know that the presence of #7033 has hindered the inclusion of many desired features in C# 12. From a future development perspective, this is absolutely reasonable and necessary. However, now that you are finally providing some clues about this feature, I would like to ask, will you address #7033 before that? Resolving #7033 and avoiding any similar issues in the future is very important. |
Beta Was this translation helpful? Give feedback.
-
|
As for InlineArrays, I totally have no idea about how this feature was even considered to be shipped, it is a completely redundant feature in C#. We even don't have an issue or discussion in csharplang repo for people in community to discuss about this. struct Foo
{
private unsafe fixed int Value[10];
public int this[int index]
{
get { unsafe { return Value[index]; } }
set { unsafe { Value[index] = value; } }
}
}and [InlineArray(10)]
struct Foo
{
private int elem;
}? So why not just make the unsafe buffer support generics and arbitrary types instead? |
Beta Was this translation helpful? Give feedback.
-
Indeed. And what we find is that we can add the new capabilities incrementally, and existing systems can take advantage. A great example of that is ref-fields, or the new 'scoped' work, which allow for simpler, faster, and safer patterns than what was previously possible. It was through our learnings from what had already shipped that we could then feed the right info into how these systems should behave. So the path we took got things out to users (and key partners like the BCL) very quickly, while also giving us the data and info on what to focus on and how it would need to work for the medium and long term. |
Beta Was this translation helpful? Give feedback.
-
|
Let's say we(not that I'm a part of the LDM in any way) were to add "const generics" in say 4 years - which could entirely supercede this If, however, const generics were implemented and it turned out they were really flawed, that would be very problematic as it's actual syntax. And that's not even taking about the fact we would be waiting for years to get what we now can get without any real irreversible decisions. (I'm only talking about the language here, not any implementation details) |
Beta Was this translation helpful? Give feedback.
-
|
@KennethHoff yup. That's exactly it. Runtime itself can also play heavily here. They are, after all, in the best place to understand what features their own libs would benefit most from. |
Beta Was this translation helpful? Give feedback.
-
|
Note: we originally had tighter language integration, but we pulled back almost universally from that since we saw some flaws we thought were awful that would plague us heavily. It's easy to just sketch an idea and go: just do this, it will be amazing! It's much harder once you actually have to make it a reality, and significant issues rise up almost immediately. |
Beta Was this translation helpful? Give feedback.
-
|
There's another problem here: if we want to bump the metamodel version, we would probably bring several features that require metamodel changes as well. So we end up needing to implement a bunch of features and the "incremental" way basically won't work here as you can't easily incrementally ship things to the metamodel: the version of C# can be bumped every year, but the version of metamodel is not. A partial list of features that need metamodel changes:
They are not something that you can achieve by relaxing the existing metadata, so all of them require changes to the existing metamodel. If we don't start to design and spec them today and instead postpone them year after year, we may never be able to reach the point where we can really start to implement those features and whenever we want to ship something need changes to the metamodel, we end up with such hacky way just like the InlineArray today. Worth to note that we have stayed on metamodel v2.0 for almost 22 years, and the last time we bumped the version of metamodel is because we wanted to introduce generic types to .NET. |
Beta Was this translation helpful? Give feedback.
-
|
What astonishes me the most is the reactions of developers that features are pulled out of a release. Although most developers probably are more used to delaying releases because features are not yet ready. |
Beta Was this translation helpful? Give feedback.
-
|
For an LTS this has to be the worst C# version ever. Of course, all the things that we really needed are not implemented, and cut again, and again. C# team kind of like old Microsoft now, especially Cyrus which literally doesn't care about what other people think about the language and will always respond to most of the posts and comments about how he think the language might be better, and how other things that the team wants to implement limit how well they are doing the things that are likely to implement (cut), which makes no sense at all. It's crazy to me, maybe you need to stop posting a version a year if you are going to release a version of C# like this with virtually 0 features, because the ones you decided to implement where for even more partial stuff, or things with a lot of negative feedback which you don't even care about, and do what the team thinks it's better, but somehow this is open source. And of course, Cyrus will respond saying that C# is open source and that we can implement those things if we could. So sad for C#. |
Beta Was this translation helpful? Give feedback.
-
Honestly, this couldn't be more off the mark.
What defines reasonable? Who defines it? Every person is likely going to have a different way of looking at things that affects their opinion here. What we do is look at things like how much impact the features bring, and how important the features are to different groups (who have different importance levels) in the ecosystem. The items we pick are drawn based on that criteria and so far has proven itself out quite well for delivering significant value the ecosystem leverages heavily.
We currently have dozens of people working on the designs and impls for c#. Doing this right takes time, and we have the mistakes of the past to show what happens when it is rushed. Work can take weeks, months, or even years depending on the enormity of the task. The challenge we have though is that ship dates are orthogonal. They are picked to maintain a regular cadence, but they will intersect that work in arbitrary places.
Again, strong disagree. Things were delayed precisely so that could be done more elegantly. Indeed, there's a tension between you asking for things to be fast and fit things to be elegant. To be elegant, the design has to consider not only the entire past if c#, but the whole future we think we want to get to. A ton of design time wrestles with this as there are twin forces (which you see in every discussion) pushing for consistency with the past versus breaking it all for a better future. This then ties into the 'reasonable' challenge. There has no right/wrong answer. And any choice will make large sets of people unhappy. So design time is spent hugely on this aspect, and we constantly revise and involve lots of effort into something we feel fits in with our legacy, but gives us a positive path to the future. That is elegance imo.
Tbh, this one is the most out there. The user base of our language is absolutely enormous, while still continuing to grow strongly. Our challenge here is that we are a jack of all trades language. Which means we compete against everything. And literally every choice we make, that gives us competitive advantages in some arenas, likely means not focusing on places that would give us and advantage elsewhere. Heck, lol at any discussion and see how some community members insist that low level improvements are the best thing for competition, while at the same time others want nothing but high-level abstractions for productivity. C# had maintained, and thrived, for so long because we do look at the programming landscape as a whole and we put our time and effort into where we think it will pay off, and to help compete in all the domains we participate in. However, as per above, we are in so many of those domains and we have so many competitors. So any particular release will not be able to compete against them all. -- Fundamentally, what I hear here is that this release isn't giving you the value you want. We hear that. But you are one of literally millions of customers. We have to make our decisions and pick out directions based on what we think will be giving the groupas a whole the best value. |
Beta Was this translation helpful? Give feedback.
-
|
@sgf's personal attack is not okay. We as a community should not be subjected to this level of degrading the quality of our conversations. |
Beta Was this translation helpful? Give feedback.
-
|
If you believe something to be in violation of the https://dotnetfoundation.org/about/policies/code-of-conduct, please feel free to make a report to conduct@dotnetfoundation.org It will be investigated by the CoC Enforcement team and appropriately handled as per dotnet-foundation/projects#174 |
Beta Was this translation helpful? Give feedback.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
|
Please stop, @sgf. As others have called out, you are personally attacking Cyrus. It's not welcome. You are causing harm, both to an individual and to this community. Please stop. Let's assume that you've got some good points within what you are saying. They are lost in the attacks and no one is listening to those points as a result. That's the opposite of "communication". If you continue this, I'll be forced to ban you from the org. I feel no need to defend against your statements, however, I'll leave the broader group with two bits of context:
|
Beta Was this translation helpful? Give feedback.
-
|
Sadly that the |
Beta Was this translation helpful? Give feedback.
-
|
Nice to see the features that I'll know about but probably never use. Curse you, C#! Why do you do everything |
Beta Was this translation helpful? Give feedback.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
|
It can be seen that everyone is generally dissatisfied with this C#12 feature update, but everyone's speeches will be in vain. I've found this not the first time, but countless times, after C# was open sourced. Thinking about your proposal, it will not be realized in 10, 20, 30 years. By then you're old, maybe even dead, and it doesn't matter if C# implements the proposal you support. This reply is my last reply. I believe this reply does not contain any personal attacks or violate any community rules, correct? Although I exposed some problems, it is clear that the development of the C# community is frustrating. I don't think I should continue to speak. Because there is no need.I figured I'd silently wish C# the best of luck. I quit the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
What |
Beta Was this translation helpful? Give feedback.
-
|
@Gammer0909 Can you be clearer on your question? :) |
Beta Was this translation helpful? Give feedback.
-
|
I was wondering what
Are |
Beta Was this translation helpful? Give feedback.
-
|
"Collection expressions" is the final name for what was originally called "collection literals". Both "collection literals" and "primary constructors" are linked to in the top post of this discussion. Thanks! :) |
Beta Was this translation helpful? Give feedback.
-
|
Ah thanks :D |
Beta Was this translation helpful? Give feedback.
-
|
Inline array link is broken |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, it's fixed now. |
Beta Was this translation helpful? Give feedback.
and others
-
As we progress toward release, we want to update you on the features that we anticipate being in C# 12.
You can get C# 12 by installing the latest Visual Studio preview or the latest version of the .NET SDK.
We are always working on a number of new features for C#, and it is the time of year where it's becoming clear which ones are likely to be ready for shipping in C# 12. The remaining features are still top of mind for future releases.
For the features that are currently in C# 12, you can find out more in What's new in C# 12 at Microsoft Learn. You can also find details about each feature in the links above, which are the same links you can find on the Roslyn Language Feature Status page.
Beta Was this translation helpful? Give feedback.
All reactions