> I agree that sigils vs generics is subjective. I don't think Python is a good argument in favour of generics though, as you say it avoids braces (and types, never mind generic types) and the problem I have with generic types is when you get a bunch of them nesting up and it all becomes hard to parse.

It uses `and` instead of `&&`, `or` instead of `||`, `list` instead of `[]` and so on.

> I would be in favour of making other more common patterns more convenient too. The difference is here we are talking about removing a convenience rather than adding one.

This isn't a common pattern though. The mention of `Box<T>` occurs a single time for each child in the type definition for a recursive data structure and isn't written out at all in the code. There aren't other common use cases. The type definitions are almost always quite short and there's no need to trim off characters.

> My point about them being self-explanatory is that you still have to go to the docs to find out what Box means, just like Vec or TreeSet. So this is not an advantage over ~.

You can easily search for "rust box" on a search engine, and it's a lot harder to search for a sigil not even found on some keyboard layouts. 

> Box doesn't tell me it is heap allocated, is implemented as a pointer, or is unique.  I disagree that Rust types are expected to be unique by default - & is the most common (non-value) type and is not unique, likewise Rc, etc. Only ~ and values are unique, and I believe most programmers with a systems background will have a mental divide between pointer types and value types.

The term box in Rust means a heap allocation, so it does tell you that. The `HashSet<T>` or `int` type doesn't tell you that it's owned in the name, so I'm not sure why you're applying this logic here but ignoring it for every other type. Unique pointers are certainly a value type, just like `Vec<T>` and `HashMap<K, V>`. All 3 of these types contain an internal pointer to their data, but have normal value semantics.

> I prefer ~[T] to Vec<T> for the same (admittedly subjective) readability reasons. I'm not sure we should be discouraging use of unique pointers. They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages. I don't think we understand the cost/benefits of idiomatic Rust programming well enough at this stage to be so bold about what programmers should be doing. In particular, the Rust code base is a compiler implementation, and compilers are a fairly unique kind of programming. We should not generalise from rustc to all programming in Rust.

I think there's little doubt that people find the sigil noise hard to understand. It doesn't exist in other languages, and it's not even familiar to C++ programmers. If Mozilla wants to start paying me for for the hours of time I spend explaining this confusing syntax to people on #rust then I'll stop complaining...

As a compiler implementation, rustc has far more recursive data structures than is the norm elsewhere. I think it's a great place to look to find out if unique pointers are commonly used. Since it's written by people who know the language, it's also a great place to look if you want to determine how frequently unique pointers end up misused due to the overly sweet syntax.

> They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages.

The normal way to do a heap allocation is by using a container performing a heap allocation internally. It's not common to be doing it manually and it indicates that the code needs refactoring or serious reconsideration.