what is the clear plans and dates about support bit-Field and support custom structure as the declaration type of fixed size buffer?

[sgf]

Although we can make suggestions, our suggestions seem difficult to get attention and adoption.
As a language closer to the bottom level than Java, C# has good language features.
For example, structure. For example pointers, such as fixed-size buffers.
However, these are not enough. I hope that C#'s native operations can be enhanced.
For example:
support bit-Field,
support custom structure as the declaration type of fixed size buffer.

I always think that these two functions are not excessive, and they are particularly important. Because this can greatly reduce the boilerplate code of C# in such scenarios.
Many people have put forward these suggestions .if you want ,i can list many similar issues, but they started to open>close>open>close again and again several years ago. This is like an endless loop, which constantly consumes people’s enthusiasm. People have to wait for the official adoption and plan to achieve. But it is disappointing that these two suggestions have not been adopted.
Now I bring up the past thing here,
I hope C# can realize these two functions as soon as possible.

Some people say it may be C#10.
But can you give a more clear time, for example:
Release Date:December 12, 2022 or December 12, 2030

#465

[CyrusNajmabadi]

But can you give a more clear time,

No. The best we can tell you are the themes were looking at. You can see that here: #4144

We don't give release dates as those are all subject to change, and we do not commit to particular releases for our features as we may delay then it cut then altogether if we do not get they are right.

[CyrusNajmabadi]

But it is disappointing that these two suggestions have not been adopted.

There are thousands of language requests happening am the time. 99% of these will not happen. If you get disappointed by that you will likely find yourself continuously disappointed in the language's progress.

[svick]

As @CyrusNajmabadi said, you're never going to get that kind of promise. The information that you can get is outlined in the README, in short:

0. If there is no proposal, nothing is going to happen.
1. If there is no championed proposal, there is no expectation that the feature is going to be added. A community ambassador (including me) can help with improving a proposal and finding a champion for it.
2. If there is a championed proposal, the timeline can be estimated from its milestone.
3. If a proposal is actively being implemented, you can see its status in Roslyn's Language Feature Status.

[HaloFour]

Feels like there should be a 2.5 in there, that a championed proposal is still not a guarantee that any proposal will be implemented, only that a member of the language design team is willing to present and argue for it's implementation at a design meeting.

[iam3yal]

People come up with loads of ideas (which is good) but in reality many of them not only are not implemented in their code but are not a problem or at least a deal breaker to begin with that the language should address and if people want these feature so much they can always fork Roslyn, implement and use whatever feature in their code but they wouldn't do it because time is precious or they have enough on their plate and yet they want the LDT to implement features because it's shiny and this is the reason for many people... some people should really understand what they are asking for.

[sgf]

I know there are many requests , but the official should understand what is important and what is not. Since C/C++ has both, I believe this feature is so important that both languages add it. Of course Many people in the C# team always think that C# should only be in line with Java, not C/C++. They even think that struct and pointers are redundant.

Since C/C++ supports BitField features, this leads to many application scenarios. People want to do it in C#, but they have to choose C/C++.
Recently C# has wasted time on adding some semi-finished features, such as: matching mode. These features not only waste a lot of team time, but every time they are released, they are semi-finished products, and it takes several version iterations to improve slightly to usable state. These syntax additions, like children, they are not well thought out. In short, they are not practical enough.

[CyrusNajmabadi]

believe this feature is so important that both languages add it.

We understand that that is what your around want. We have to weigh your wants against the thousands of other requests from the other customers as well.

[CyrusNajmabadi]

Recently C# has wasted time on adding some semi-finished features, such as: matching mode. These features not only waste a lot of team time, but every time they are released, they are semi-finished products, and it takes several version iterations to improve slightly to usable state. These syntax additions, like children, they are not well thought out. In short, they are not practical enough.

You're not winning any support from the team with posts like this. You may not have liked these features, but we felt they are all very relevant and important for the ecosystem. You're free to dislike that, but if you're not willing to understand why the team felt these were good additions, it's unlikely we going to reach any common ground in the discussions here.

[sgf]

You're not winning any support from the team with posts like this. You may not have liked these features, but we felt they are all very relevant and important for the ecosystem. You're free to dislike that, but if you're not willing to understand why the team felt these were good additions, it's unlikely we going to reach any common ground in the discussions here.

No, you got it wrong, actually I like matching patterns, but the official implementation is not elegant. What I don't like is that the official always pushes out half-finished products at the beginning, and doesn't that cause a syntax compatibility burden ? Some syntax additions are very counter-intuitive.

[CyrusNajmabadi]

but the official implementation is not elegant.

I don't know what you mean by that.

What I don't like is that the official always pushes out half-finished products at the beginning,

Again, you're not winning support here.

and doesn't that cause a syntax compatibility burden ? Some syntax additions are very counter-intuitive.

You're welcome to think that. But see the above post. It would be worthwhile to understand why we do not think the same way.

[sgf]

When people get used to using other languages to solve problems, then of course there will be fewer and fewer people like us making requests. In the end, perhaps this proposal will be ignored.
But I still hope to try again, try again, try again, and hope that one day it will attract the attention of the team members.

[CyrusNajmabadi]

When people get used to using other languages to solve problems, then of course there will be fewer and fewer people like us making requests.

This is not actually true. We see requests for features from other languages that get a ton of requests and continual interest.

Sometimes something has lost interest because the community is genuinely less interested in it.

[sgf]

I think C# is hard to popularize and not popular enough. It's because many people just use it as another java. So why don't people just use java? Not to mention the better and more radical Kotlin.
So, what is the purpose of C#? Just a better Java.
Where are the characteristics of C#, and where is the competitiveness of C#.
Of course, there are areas where people don't seem to show great enthusiasm. But isn't it because these areas should be solidified.
Even though C# has structs and pointers, 90% of C# developers don't use it. Even when application performance bottlenecks, they are still just complaining that C# isn't fast enough.

[CyrusNajmabadi]

So, what is the purpose of C#

To be a general purpose programming language for many domains and users.

It's a very popular language and continues to grow.

There are also thousands of requests from people on things we could do to change it. If you want your suggestion to be taken seriously, you need to show that it is actually very important to growth here, and not yet another feature that a tiny group just just really really likes.

[sgf]

Today, C# still occupies a certain share, which is actually closely related to the success of C# in the game field, which is due to Unity’s choice of C#.This is also thanks to C# being close to C/C++, otherwise C# would not have a chance to be the choice for Unity.

[CyrusNajmabadi]

I'm not sure what your point is here. C# is popular, with a huge user base. We are constantly assessing that user base and all the suggestions we get to try to determine a great set of features that will provide a ton of value.

Are there features that might benefit a tiny group a huge amount? Sure.. but they're are often many other features that would benefit a larger group an even larger amount.

Given our finite resources we are always triaging and trying to determine the right set to work on.