when watching this talk, i had to agree to the argument
std::unique_ptr<Stuff> makes “Stuff” look like the unimportant part, whereas everything we care about when handling variables of this type is that it’s a pointer to “Stuff”.
we offset this by making the alternative pointer types’ names really short, but i think we should make it explicit that it’s a “Rc|Box|… pointer to Stuff”, not some other generic type “List|Tree|… of Stuff”.
syntax could be like let stuff: &Rc Stuff = ..., or Rc& Stuff, which both can synergize with the &mut syntax.
a Box<List<T>> would then become a Box& List<T> or a &Box List<T>, which both look more semantic to me.
really I just preferred the way it used to work. ~T, and the way ~ combined for ~str, ~[T] - even though it was slightly magical/hardcoded , I could imagine it eventually being like an overloaded operator working in the type-syntax-‘get the uniquely-owned version of X’ rather than just ‘a uniquely ptr to (X)’, or generalised operator-overloads. Even though hard coded I saw value to it: like C++ had done the R&D with templates , and Rust had hard-coded special syntax for the emergent patterns. compare to lisp starting out with completely general syntax, then infix languages gave more convenient ways of writing the same things.
It was very quick to pick up & learn, and read logically - because one a few symbols ~,str,[] combined to give you a lot.
It led to criticism that ‘rust had too many pointer types’ but all that changed was they made them more verbose… thats just silly people criticising - anyone who actually NEEDS rust realises many pointer types are essential.
but failing that: I also agree that moving to square brackets X[T] for types would also be a step forward; they do seem to look less obtrusive. Coming from C++ the angle-brackets are part of its’ syntactic curse. There’s less shift-key use so its’ easier to type.
Also maybe syntax highlighting could help? :…< or :…[ could be de-emphasised with colorcoding?