Add question about missing features

[apiraino]

closes #238

Ideas for more options? I guess here @alice-i-cecile has some suggestions 🙂

EDIT: Rendered view

[alice-i-cecile]

The language roadmap is a good place to start.

My initial list:

• variadic generics
• const float arithmetic
• const trait methods
• type alias impl Trait
• generators
• custom library compiler messages
• stable Rust ABI
• relaxed orphan rules
• const generics for custom types
• complex const generic expressions
• compile time reflection

I'll ask around too: I'm sure others will have good ideas for WIP / discussed features that I've never heard of.

[iiYese]

A few I don't see listed yet:

• Generic specialization
• HKTs
• Working lending iterators
• ?mut (maybe mut)

[PROMETHIA-27]

Adding to generators; I'm unsure of the current plans for them, but having them be full coroutines (able to take a parameter each yield like let x = yield y;) would make additional patterns viable with them. It seems like the trait supports this but the syntax does not.

[kornelski]

• Specialization
• OOM=panic and better OOM handling in std
• pointer metadata (custom DSTs), len working on *const [T]
• if-let chains

[jyn514]

Please add an option for "I would prefer the language not to add major new features."

[Selene-Amanita]

I guess it falls under "stable Rust ABI" but yeah an easier way of making dynamic libraries and have a "plugin" system.

More flexible if let chains, like mixing normal ifs and if let, I didn't follow closely but I think it's still not possible or at least stable?

[apiraino]

I wonder if linking a work in progress document or an RFC (if existing) could help. Some of the suggested options are unclear to me. On the other hand if I were to fill the survey and I don't know what "HKTs" are, they are probably not important for me (or they are something I need without knowing how they're called).

@Kobzol ?

[pacak]

I don't know what "HKTs" are, they are probably not important for me (or they are something I need without knowing how they're called).

https://serokell.io/blog/kinds-and-hkts-in-haskell

Currently things like Option<usize> are types, but there's no way to talk about just Option by itself. At the same time you can think of it as a function on a type level: it takes a type and gives you a type back. Similarly Result needs two types to give a type back. This is opens a bunch of interesting possibilities.

[alice-i-cecile]

I wonder if linking a work in progress document or an RFC (if existing) could help. Some of the suggested options are unclear to me.

Yep, I think we should do this wherever possible.

[pacak]

To add to the list: type families - https://wiki.haskell.org/GHC/Type_families

Similarly how HKT give you some notion of function on a type level (you apply type usize to function Option and get a type Option<usize> back), type families further extend it by allowing you to use pattern match like syntax to generate arbitrary types

Consider a database table user:

struct User {
    id: usize,
    login: String,
    ...
}

To insert something you'd need User itself, to update it - you might want to have a copy of User where all the fields are Option of whatever value it was. To return the validation errors - same, but all the fields are Result.

With HKT you can have something like this:

struct User<F> {
    id: F<usize>,
    login: F<String>,
    ...
}

So User<Option>, User<Result<String>> are all those intermediate items. And with type families you can have a magical type level function Id such that User<Id> is not a user where every field is wrapped in Id, but every field is the inner value by itself.

[pacak]

• Currying/partial application

[Kobzol]

I would include things in the list that are currently at least partially implemented and are (at least in theory) on some way towards stabilization. So generators or specialization 👍, more abstract things like currying/HKTs perhaps not. To formalize this idea, and to have some sorts of prioritization, I would go through something like this: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3AC-tracking-issue (the most liked tracking issues) and select first N features, plus maybe a few additional ones, according to some upper bound (let's say 12 answers at most?).

There's always some features that we will miss, and that is fine, as they can be entered using the free form answer.

[dmyyy]

• Enum variant types

[Kobzol]

Yeah and linking RFCs or tracking issues is a good idea, provided that SurveyHero can render the links reasonably.

[Kobzol]

The first 12 features from this list:

• specialization
• if/while let chains
• try blocks
• type alias impl trait
• coroutines/generators
• trait alias
• async closure
• async fn in trait (I would ignore this one though, since it's almost stabilized already)
• never type
• associated type defaults
• implied bounds
• Vec::extract_if (I think that this one is too specific and shouldn't be added as an answer :) )

(This method of finding features is a bit flawed by the fact that these issues have gathered likes for a long time, but they don't necessarily represent the most pressing issues of Rust users today.)

And here are the things that are not in that list, but were mentioned on this PR so far:

• variadic generics
• const float arithmetic
• const trait methods
• custom library compiler messages
• stable Rust ABI
• relaxed orphan rules
• const generics for custom types
• complex const generic expressions
• compile time reflection
• HKTs
• Working lending iterators
• ?mut (maybe mut)
• OOM=panic and better OOM handling in std
• pointer metadata (custom DSTs), len working on *const [T]
• enum variant types

Since it's too many, I think that we should either not add some of them, and/or group some of the others together.

Something like this:

• specialization
• generators/coroutines
• async closures
• if/white let chains
• try blocks
• never type
• improved traits (trait alias, implied bounds, associated type defaults)
• improved const (generic const expressions, const expr for custom types, const trait methods)
• compile time reflection (variadic generics)
• enum variant types
• allocator trait, better OOM handling
• stable ABI
• relaxed orphan rules
• custom library compiler messages

That's still not 12, but 14 :) I'm not sure if "Stable ABI" is something that belongs with the other things, but it's a very important topic nonetheless.

Also, I think that we should include something like @jyn514 has mentioned, e.g. I would prefer the language not to add major new features. or I would prefer the language to slow down the introduction of major new features.

[alice-i-cecile]

I would go with:

1. I want Rust to slow down or stop the introduction of major language features.
2. Specialization
3. Generators/coroutines
4. Async closures
5. If/white let chains
6. Try blocks
7. Never type
8. Improved traits (trait alias, implied bounds, associated type defaults)
9. Improved const (generic const expressions, const float arithmetic, const expr for custom types, const trait methods)
10. Compile time reflection
11. Variadic generics
12. Allocator trait and better OOM handling
13. Stable ABI
14. Other

Compile time reflection and variadic generics are unrelated. const float arithmetic was added, enum variant types was problematic last I checked on it, relaxed orphan rules is ambiguous, custom library compiler messages are not really a lang team concern.

[Kobzol]

Compile time reflection and variadic generics are unrelated. const float arithmetic was added, enum variant types was problematic last I checked on it, relaxed orphan rules is ambiguous, custom library compiler messages are not really a lang team concern.

I wouldn't say that they are unrelated (possibly variadic generics could be needed for reflection), but yeah, that was a desperate attempt at joining some answers together 😆

[Kobzol]

@alice-i-cecile's list looks good to me. Maybe we can wait for some input from the lang team.

[alice-i-cecile]

Yep, I pinged them on Zulip but no response yet. Gathering links is probably the next step to move this forward right?

[kornelski]

Maybe "improvements for working with unsafe code" would cover a lot of features?
(Pointer metadata, out references, -> operator, memory mapped io semantics mentioned here: https://security.googleblog.com/2023/10/bare-metal-rust-in-android.html)

[jyn514]

Kornel's comment has actually helped me identify my main objection to this question. Why ask about specific language features? Ask about the problems people are having (MMIO is hard, io::Write requires the memory to be initialized, the learning curve from Haskell is painful), not the solutions people want (opt out of provenance, out references, HKT). That's closer to what you care about anyway, and lets lang team design features that better fit the use cases.

[Kobzol]

That's a good point, in general. However, I think that it might be quite difficult to describe these difficulties with a closed answer containing 4-5 words.

Like "I struggle with unsafe code" is valuable, but by itself does not tell us what exactly should be prioritized. While "async closure" does not tell us the motivation, but it's a very specific feature and a clear work package for prioritization.

[Kobzol]

Also, since this should serve as a prioritization poll, we should only allow N (3?) answers at most (if SurveyHero allows it). Otherwise many people will just check everything.

[jyn514]

but this doesn't tell you anything about how things should be prioritized! to do that you have to consult with lang/compiler/libs-api anyway, since they're the ones who work on features.

you're choosing the question to make it easy to say "this is the most requested feature", but that's never been how rust works - it's grass-roots, teams say which work they want to do and volunteers pick what they're interested in regardless of what has the most thumbs-ups. if you're going to consult with lang anyway, you may as well give them the data that they need to make a decision, not a pre-determined list for them to accept or veto.

[jyn514]

at the very least I would suggest talking to lang team and asking them if the information from this question would be useful, and if not, what would be more useful.

[Kobzol]

at the very least I would suggest talking to lang team and asking them if the information from this question would be useful, and if not, what would be more useful.

Yeah, we have pinged the lang team on Zulip and are awaiting some response. We're still brainstorming this question, it's not clear whether it really will be added this year and whether it will look like a list of features - that's still up to discussion :)

I understand your view, and I agree that your approach makes more sense. What I'm not sure about is whether it is possible to gather the sentiment that you are describing in a single poll question with closed answers. If we want to go this route, maybe it would be best to just leave this question just with an open answer, without any predetermined options.

I agree that ultimately the lang team should be the deciding factor here, hopefully someone will chime in.

[djc]

I would suggest something like "Making it easier to write panic-free code".

[apiraino]

I'm starting to think this question has many facets and that deserves a full reasoning apart. The survey might be a tight container for it. I'm thinking to #188 as a possible container for such inquiries to the community.

So, yes, let's brainstorm on these options and add them to the survey but by no means I think they will tell us the whole truth. Therefore I think it's fine if these options won't make everyone 100% happy (to be clear: @jyn514 I really like and share the points you make).

[apiraino]

We want to thank everyone (and T-lang from Zulip) that contributed with suggestions. Your contributions were greatly appreciated!