MORE colored function.
This is an hw interrupt/event system callback/gui thred, you can only use other similarly colored functions.
We may need color palette and prims, and of course a specialized unsafe{}, "colorblind{}"
Some sort of *context parameter*. Like `self` but is `context` instead. Would be accessible in `PartialEq` traits and such. Seems like it would make custom allocator stuff much more approachable.
- get rid of Mutex poisoning
- compile-time reflection system to greatly simplify serialization, etc (don’t know what this would look like actually)
- Either type in std… or even better: unions
- make orphan rules into a deny-by-default lint
both tokio’s and parking_lot’s mutexes just release the lock on panic instead of poisoning. I think poisoning is well-reasoned, but it feels a little too opinionated for a std primitive. i personally would’ve preferred std’s mutex to not poison and to just release on panic too
IIRC the idea with poisoning was: some critical code locks a mutex, partially updates it but panics, leaving a bad value in the mutex. poisoning prevents future code from using this bad value
if std didn't poison, a library could handle it, but i'd guess most code doesn't really need it anyway
Oh, another one that just came to mind. Remove/change tuple field access syntax, the parsing/lexing ambiguity it causes with float literals is an absolute pain to handle especially together with macros.
I guess I would've liked the types of references expanded:
- NonCell &muts: can safely degrade to &
- Aliasing groups: multiple &mut/& form a group, all of them can be used as &'s together but once one is used as &mut all the others invalidate
- True reborrowing
Give me these three, and I can use the borrow checker / references to model both a GC's memory management (normal &mut XOR &'s) AND its internal reference validity (multiple &mut AND &'s, &mut is used for GC and invalidates existing references).
- Move trait and/or drop takes &Pin
- const by default
- cargo organisations/namespaces or atproto compatible somehow
- raw keywords & identifiers from the get go
In addition to some good one already mentioned: more async abstractions. I appreciate there are good reasons to not include an async runtime, but we all end up writing incompatible (due to orphan rule) abstractions making mixing and matching crates a nightmare.
Allow for struct and enum definitions to contain struct and enum definitions rather than having to define everything at the root level and then include them later. These temporary structs are probably my biggest sadness
Implement https://github.com/rust-lang/rfcs/issues/997 so I can mutably access elements in a HashMap with the index operator. Also I find it very ugly that being able to move out of a Box with the dereference operator is specific to the Box type and cannot be done with any other type.
Alternatively, if that's too hard for some reason, another thing I thought of is replacing `if let` and `while let` by the `is` operator, as described in https://github.com/rust-lang/rfcs/pull/3573.
Removed `as` casts in favour of specific traits (possibly with some sugar) for each different thing `as` is used for. Still vaguely hoping we can eventually deprecate them, but wow it's a journey.
Hhhhm, on the hot topic of language syntax, I would have a single expression for pattern matching (`is` or `let` expression, like the contentious RFC of last year) and use `[]` instead of `<>` for generics (byebye turbofish).
On more controversial topics, I would use kebab-case for identifiers (IMO the most readable naming convention, although quite rare unfortunately), use `.` everywhere instead of `::` (so ugly !), and use indentation-sensitive grammar instead of braces.
Also use PascalCase even for primitives types, use `Never` for the never type (why use a symbol for something so rare !), and a pronounceable keyword for functions (`fun`, `func`, `def`...).
My complaint is that almost every api from std on wasm32 is either unsupported (but it panics instead of being a compiler error), or has silently different behavior (e.g. HashMap is deterministic). The few things that do work (e.g. Read trait?) are niche and proposed to move to core anyway.
hmm. i would kill let mut. all local bindings should be mutable. making them immutable isn't necessary for borrowck correctness, you only need immutable references for that. kinda how there isn't an immutable box
also I would have made non_exhaustive on structs only require that struct literals and patterns involving that struct require .. when outside of the defining crate (today non_exhaustive is totally broken on structs)
Comments
This is an hw interrupt/event system callback/gui thred, you can only use other similarly colored functions.
We may need color palette and prims, and of course a specialized unsafe{}, "colorblind{}"
i haaaate relying on compile testing to check for alloc usage in a scope. sooo annoying.
would rather it be denied like std.
- compile-time reflection system to greatly simplify serialization, etc (don’t know what this would look like actually)
- Either type in std… or even better: unions
- make orphan rules into a deny-by-default lint
if std didn't poison, a library could handle it, but i'd guess most code doesn't really need it anyway
let -> (mut implied)
- NonCell &muts: can safely degrade to &
- Aliasing groups: multiple &mut/& form a group, all of them can be used as &'s together but once one is used as &mut all the others invalidate
- True reborrowing
- const by default
- cargo organisations/namespaces or atproto compatible somehow
- raw keywords & identifiers from the get go
The happy path should come first, and the else condition should come second.
All doable - and some is already done - but time and resources are scarce.
and maybe I would have made it so you couldn't form references to fields by default, to enable more aggressive layout optimization (viz repr(packed))
i would have not made fnptrs implement PartialEq.
i would have made enum variants private by default
I would have made Iterator::Item a GAT so that each call to .next() could borrow the iterator