6 ms·
There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind ch
by eklavya 12y ago
There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".
- steveklabnik 12y agoI'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ? Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
- eklavya 12y agoSomething has precedent doesn't mean you ought to do it. kibwen explains the reason above.
- steveklabnik 12y agoWhile this is true, that doesn't mean precedent is irrelevant. While what kiwiben said is true, https://github.com/rust-lang/rfcs/pull/148#issuecomment-47718999 https://github.com/rust-lang/rfcs/pull/148#issuecomment-4771...
- kibwen 12y agoLanguage design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM
- dbaupp 12y agoI maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.
- mercurial 12y agoI don't know about Clojure, but . in Java is ambiguous in the grammar, since it's also used for method calls. And . is function composition in Haskell. I can understand why Rust would want a different sigil.
- Dewie 12y agoI think I saw some proposal to replace the function composition from prelude (.) with some other symbol, and presumably making it illegal to define operators named (.). This would of course break a lot of code, but it seems simple enough to make a largely automated transition. The reason for the proposal was that (.) for function composition made the grammar more complex or problematic because of the accessing 'operator' (.), and/or something that had to do with more fancy accessing and such (lenses?).
- dscrd 12y agoIf it's meant to signify paths, why not use the sigil that everyone uses for path separation, i.e. /
- kibwen 12y agoBecause this is ambiguous in any language that uses that same character as the division operator. The compiler wouldn't be able to tell whether `foo/bar + 2` is "divide foo by bar, then add two" or "add two to the bar item found in the foo namespace". Theoretically it's solvable by requiring whitespace to surround all arithmetic operators, which is actually a bit of an intriguing proposition because it would then also allow you to use dashes in variable names and have it be unambiguous, i.e. `foo-bar/qux - baz / spam` would unambiguously mean "divide baz by spam, then subtract it from qux in the foo-bar namespace". But nearly all languages try to avoid this sort of whitespace dependence (look at the ancient furor over the `> >` requirement in C++), and it would be quite a reach for Rust to start championing it now.
- kibwen 12y agoThe reason for <> instead of [] is that both are just as ambiguous to Rust's grammar, and that <> is, unfortunately, more-or-less the industry standard (C++, Java, and soon Swift). I would personally prefer something akin to D's generic syntax (but with a different symbol, since the exclamation point already has meaning in Rust). The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)
- wtetzner 12y agoHonestly, it's kind of sad that things are chosen because they're industry standard, instead of how good/nice they are. After using Scala, I think that []'s are much easier on the eyes than <>'s.
- kibwen 12y agoWhen designing a language, you have to decide which hills are worth dying on. Uglier it may be, but if using <> makes our syntax more immediately recognizable to C++ developers, then we have a better chance of succeeding in bringing safety to the low-level niche where C and C++ reign supreme. Don't worry, once Rust has established a foothold here, then we can start designing the pretty language that will usurp it. :)
- eklavya 12y agoI really really hope it changes to [] in future. I am scared of the code with lots of <>, I don't know why but I lose context.
- frowaway001 12y agoI agree with that. Having worked with languages which use <> and Scala, [] are just magnitudes more readable when expressing the same types.
- 12y ago