Kind of curious where all this syntax talk came from given neither the article nor other comments are talking about it. Much of the rest seems to have a tenuous connection at best to the comment you are replying to.
That being said...
> For instance, why copy C++'s "::" for paths when Rust was a greenfield programming language without the burden of backwards compatibility?
The concept of a strangeness budget [0] is probably relevant here - if you want to appeal to a particular audience (C++ programmers in this case), you probably want to limit "strangeness" to places where it's likely to make the largest impact. From this lens it might be interesting to look at your question from the other direction: What would the benefit be of not copying C++'s syntax in this context, if any, and is that worth spending part of your strangeness budget?
Also this comment [1] from a few days ago seems well-timed, though it's answering a slightly different question:
> The `::` syntax allows the compiler to identify and resolve all the static paths before any type inference or other analysis. This is important because macros are expanded between these stages, and can in turn introduce more static names which must also be resolved before any further compilation.
Unfortunately I haven't been able to find an authoritative explanation of why :: instead of something else, though given how old it is [2] I'd guess it's one of those strangeness budget decisions.
> ("= Expression except LazyBooleanExpression or end with a }").
Based on the syntax diagram this bit is for let-else. If you look at the RFC [3] you'll get the answer you seek:
> While allowing e.g. if {} else {} directly in the expression position is technically feasible this RFC proposes it be disallowed for programmer clarity so as to avoid ... else {} else {} situations as discussed in the drawbacks section. Boolean matches are not useful with let-else and so lazy boolean expressions are disallowed for reasons noted in future-possibilities. These types of expressions can still be used when combined in a less ambiguous manner with parentheses, which is allowed under the two expression restrictions.
> Turbofish, could probably have been avoided by not using "<" and ">" both as type argument delimiters and as an operator for comparison. Scala 2 for example does it differently, using "[" and "]" for type argument delimiting.
Rust did in fact use square brackets for generics early on, but that was later changed to angle brackets [4, 5]. I haven't been able to dig up explicit discussions as to why, though again I suspect strangeness budget concerns were at least part of the reason.
Using square brackets for types is probably not a change that can be made in isolation either; at a minimum you'd need to consider how that interacts with indexing/function calls/etc. and how those in turn interact with traits (e.g., if manual implementation of function traits is ever stabilized).
Also, from what I understand the turbofish was never strictly necessary, and in fact it actually is possible for Rust to eliminate the need for the turbofish thanks to the magic of editions ([6]). It's "just" a matter of someone taking up the cause and gathering sufficient consensus.
> Using two different operators for what one could call "type annotations", namely both ":" and "->", in different cases, feels ugly to me.
You might find this email from Graydon Hoare interesting [7]. Among other things he says:
> If the argument's about consistency, I think the consistent thing to do is to keep ":" as a separator between bindings and types. My eyes get a little fuzzy guessing the associativity of "let x : fn(T) : U;" in a way that they do not when reading "let x : fn(T) -> U;". But I suppose reasonable people could disagre, or phrase the consistency requirement differently. My math professors would cry.
[0]: https://steveklabnik.com/writing/the-language-strangeness-bu...
[1]: https://news.ycombinator.com/item?id=50369228
[2]: https://web.archive.org/web/20130118053116/http://static.rus...
[3]: https://rust-lang.github.io/rfcs/3137-let-else.html
[4]: https://github.com/rust-lang/rust/commit/70b009178cf050d5bb7...
[5]: https://github.com/rust-lang/rust/commit/0107d6a81d2180d3a1e...
[6]: https://github.com/rust-lang/rfcs/pull/2544
[7]: https://web.archive.org/web/20201111221825/https://mail.mozi...
That being said...
> For instance, why copy C++'s "::" for paths when Rust was a greenfield programming language without the burden of backwards compatibility?
The concept of a strangeness budget [0] is probably relevant here - if you want to appeal to a particular audience (C++ programmers in this case), you probably want to limit "strangeness" to places where it's likely to make the largest impact. From this lens it might be interesting to look at your question from the other direction: What would the benefit be of not copying C++'s syntax in this context, if any, and is that worth spending part of your strangeness budget?
Also this comment [1] from a few days ago seems well-timed, though it's answering a slightly different question:
> The `::` syntax allows the compiler to identify and resolve all the static paths before any type inference or other analysis. This is important because macros are expanded between these stages, and can in turn introduce more static names which must also be resolved before any further compilation.
Unfortunately I haven't been able to find an authoritative explanation of why :: instead of something else, though given how old it is [2] I'd guess it's one of those strangeness budget decisions.
> ("= Expression except LazyBooleanExpression or end with a }").
Based on the syntax diagram this bit is for let-else. If you look at the RFC [3] you'll get the answer you seek:
> While allowing e.g. if {} else {} directly in the expression position is technically feasible this RFC proposes it be disallowed for programmer clarity so as to avoid ... else {} else {} situations as discussed in the drawbacks section. Boolean matches are not useful with let-else and so lazy boolean expressions are disallowed for reasons noted in future-possibilities. These types of expressions can still be used when combined in a less ambiguous manner with parentheses, which is allowed under the two expression restrictions.
> Turbofish, could probably have been avoided by not using "<" and ">" both as type argument delimiters and as an operator for comparison. Scala 2 for example does it differently, using "[" and "]" for type argument delimiting.
Rust did in fact use square brackets for generics early on, but that was later changed to angle brackets [4, 5]. I haven't been able to dig up explicit discussions as to why, though again I suspect strangeness budget concerns were at least part of the reason.
Using square brackets for types is probably not a change that can be made in isolation either; at a minimum you'd need to consider how that interacts with indexing/function calls/etc. and how those in turn interact with traits (e.g., if manual implementation of function traits is ever stabilized).
Also, from what I understand the turbofish was never strictly necessary, and in fact it actually is possible for Rust to eliminate the need for the turbofish thanks to the magic of editions ([6]). It's "just" a matter of someone taking up the cause and gathering sufficient consensus.
> Using two different operators for what one could call "type annotations", namely both ":" and "->", in different cases, feels ugly to me.
You might find this email from Graydon Hoare interesting [7]. Among other things he says:
> If the argument's about consistency, I think the consistent thing to do is to keep ":" as a separator between bindings and types. My eyes get a little fuzzy guessing the associativity of "let x : fn(T) : U;" in a way that they do not when reading "let x : fn(T) -> U;". But I suppose reasonable people could disagre, or phrase the consistency requirement differently. My math professors would cry.
[0]: https://steveklabnik.com/writing/the-language-strangeness-bu...
[1]: https://news.ycombinator.com/item?id=50369228
[2]: https://web.archive.org/web/20130118053116/http://static.rus...
[3]: https://rust-lang.github.io/rfcs/3137-let-else.html
[4]: https://github.com/rust-lang/rust/commit/70b009178cf050d5bb7...
[5]: https://github.com/rust-lang/rust/commit/0107d6a81d2180d3a1e...
[6]: https://github.com/rust-lang/rfcs/pull/2544
[7]: https://web.archive.org/web/20201111221825/https://mail.mozi...