> Having smart pointers as sigils rather than generics makes reading (and writing) Rust much nicer than the equivalent C++.

That's quite subjective, as I think it's far easier to read when it's using normal syntax instead of a special case in the language. Unique pointers are rarely used, and when they are they're rarely spelled out due to type inference. There are far more common patterns, so I don't understand why this one would deserve syntax hard-wired into the language. Even a module like `collections::treemap` based on unique pointers barely uses the sigil.

> it doesn't tell us anything about how the type behaves or how it is different from &, *, Rc, etc.

It behaves as a normal owned type with a destructor, just like a `Vec<T>` or a `HashMap<K, V>`.

> Having more than one way to do something is a noble goal, but we have to balance that against convenience. In this case there is a clear way to decide which to use (whether you are using an allocator or not) and we could even enforce that with a lint.

It doesn't make sense to add conveniences for things that are rarely used and meant to be discouraged.

> I'm not sure about the 'blindly adding sigils' thing. It kind of seems like a reasonable argument, but do we know people don't do it?

Few people learning Rust understand that unique pointers are not special and could be implemented in a library. It's clearly not something that's going to get across to newcomers. I've explained this thousands of times to people in #rust... it would be nice if the language just made some effort to avoid obscure, confusing syntax in the first place.