Looking at the big picture/requirements rather than solutions, etc. I think it is great to push on this stuff, I’m especially keen to see us tackle some of the smaller, low-hanging fruit solutions rather than the sweeping changes. I think focussing on ergonomic paper cuts is way to get big returns for relatively little effort and with relatively few risks to the language. In contrast, I worry deeply about adding to our complexity budget with big new features.
The fact that string literals have type &'static str which cannot be readily coerced to String
ref and ref mut on match bindings are confusing and annoying
lexical lifetimes on borrows
Fiddling around with integer sizes
These all seem like pure win to me. NLL are a big issue, I don’t think it significantly affects the complexity of the language (for users, clearly it complicates the implementation). However, I think we have significant non-technical debt in terms of documentation and tooling for lifetimes/borrowing and I think this feature adds to that debt. We should prioritise paying some of it off too.
References to copy types (e.g., &u32), references on comparison operations
I think this a worthy target, but whether it can be addressed depends on the solution. If there are nice solutions it seems like something good to do.
Some kind of auto-clone
This I’m not keen to think of as a goal. If we want to tackle the higher-level space, then I think we need to think hard about an holistic strategy rather than polishing specific pain points that might be detrimental elsewhere. Put another way, although it is annoying, I don’t think cloning
Arc is a pain point for most Rust code today.
By strategy, I mean that maybe for higher-level programming we want a new type like
Gc which didn’t need cloning or even a new language (RustScript!) or language mode. I.e., there may be bigger language changes that give the desired ergonomics here.
#[derive(PartialEq, Eq, PartialOrd, Ord, Copy, Clone, etc)]
derive shorthands seem like an obvious and low cost thing to add, I’d love to see this.
language-level support for AsRef-like pattern
Could you expand on why you think this needs language-level support? My experience has been that (mostly) it works smoothly as is. The risk/reward on this one seems much higher than the others.
lifting lifetime/type parameters to modules
I would like to see this, but it does seem to add to the complexity budget a bit. I’d be happy to put this one off for a while longer.
inferring T: 'x annotations at the type level
Would be great to play around with elision/inference here.
explicit types on statics and constants
I think we could cautiously add more inference here, perhaps starting by bailing if we need cross-item dependencies?
Trait aliases (as in something like
type but for traits) seem quite different from inferred bounds, why do you think they are related? I’m very keen on trait aliases, not sure about inferring bounds
We’ve also discussed type and lifetime parameters on
impls as a paper-cut we might tackle.
I’ve warmed up to the idea of getting rid of
extern crate, although I’m still not very convinced it would buy us a lot.
Seems worth thinking about if we can simplify the module rules too.
I would also like to tackle some of the boilerplate around structs (derive(new), default values for fields), and add enum variant types (currently blocked on finalising the default generics stuff).
I want enough of CTFE stabilised to have
#[transparent] (#1744) for easing the ugly stack traces we give out.
On the bigger items, I strongly think we should focus on finishing off the stuff we have in flight, rather than adding to that mountain. It would be much better for the language to finish and stabilise specialisation, impl trait, default generics, CTFE, allocators, etc. than to start on const generics, virtual structs, or HKT-ish stuff.