Would love this. I've heard it's not planned to be in the near future. Maybe "perfect is the enemy of good enough"?

There is a GitHub issue that details what's blocking stabilization for a each feature. I've read a few recently and noticed some patterns:

1. A high bar for quality in std

2. Dependencies on other unstable features

3. Known bugs

4. Conflicts with other unstable features

It seems anything that affects trait solving is very complicated and is more likely to have bugs or combine non-trivially with other trait-solving features.

I think there is also some sampling bias. Tons of features get stabilized, but you are much more likely to notice a nightly feature that is unstable for a long time and complex enough to be excited about.

There really aren't that many people working on the compiler. It's mostly volunteers.

The structure is unlike a traditional company. In a traditional company, the managers decide the priorities and direct the employees what to work on while facilitating that work. While there are people with a more managerial type position working on rust compiler, their job is not to tell the volunteers what to work on (they cannot), but instead to help the volunteers accomplish whatever it is they want to do.

I don't know about std::simd specifically, but for many features, it's simply a case of "none of the very small number of people working on the rust compiler have prioritized it".

I do wish there was a bounty system, where people could say "I really want std::simd so I'll pay $5,000 to the rust foundation if it gets stabilized". If enough people did that I'm sure they could find a way to make it happen. But I think realistically, very few people would be willing to put up even a cent for the features they want. I hear a lot of people wishing for better const generics, but only 27 people have set up a donation to boxy (lead of the const generics group https://github.com/sponsors/BoxyUwU ).

Usually when I go and read the github and zulip threads the reason for paused work comes down to the fact that no one has come up with a design that maintains every existing promise the compiler has made. The most common ones I see are the feature conflicts with safety, semver/encapsulation, interacts weirdly with object safety, causes post post-monomorphization errors, breaks perfect type class coherence (see haskells unsound specialization).

Too many promises have been made.

Rust needs more unsafe opt outs. Ironically simd has this so it does not bother me.

I would love generators too but I think the more features they add the more interactions with existing features they have to deal with, so it's not surprising that its slowing down.

I'm not a rust programmer.

Can't you just make a local copy of the existing package and use that? Did you need to re-implement?

Why would that be odd? C# is an older and mature language backed by a corporation, while Rust is younger and has been run by a small group of volunteers for years now.

C# is blessed on that front. Java’s SIMD state is still sad, and golang is not as great either.

It's not strictly x86 either, the other case you care about is fp16 support on ARM. But it is included in the M1 target, so really only on other ARM.