4 ms·

And yet the decision to keep <> as the type annotation container was made entirely on the basis of familiarity, despite the fact that most people in the discuss

And yet the decision to keep <> as the type annotation container was made entirely on the basis of familiarity, despite the fact that most people in the discussion personally preferred the more intuitive and readable but unfamiliar syntax inspiration from D or Scala. They didn't want to alienate the C++ crowd. There are lots of competing ideologies about syntax in the rust community. Not everybody thinks the same way.

steveklabnik 12y ago
> was made entirely on the basis of familiarity, This is sorta kinda true. A long time ago, Rust used `[]`s. Then, at some point, it changed to `<>`s. When the discussion you're referring to came up, it was determined that there wasn't a good enough reason to switch back to `[]`s, as that also introduced other problems, and so wasn't clearly better, and would introduce a lot of churn.
- frowaway001 12y ago
  I'd love to know which problems that would have introduced. Rust's choice of <> ignored the lessons from all the language which made that choice before (Java, C#, C++) and from there, other bad ideas just snowballed on top of it.
  - steveklabnik 12y ago
    Since it's also used for array access, it introduces another ambiguity in the grammar there.
    - saosebastiao 12y ago
      The ambiguity had a clearly proposed fix in the issue thread: use () for array access. Just like in scala. Lots of people were clamoring for the change, and the only unaddressed opposition to it was from those that explicitly wanted to cater to the c++ familiarity.
      - dbaupp 12y ago
        Using () doesn't work without introducing yet more concepts to the language, to make both let element: i32 = some_integer_array(i); let reference: &i32 = &some_integer_array(i); work. In particular, the second one should give a reference to the element inside the array. I believe Scala doesn't have to deal with this subtlety, since everything is a pointer and generally the precise location of things in memory isn't so important. This issue is definitely not insurmountable, but it is also definitely not a simple direct replacement.
        frowaway001 12y ago
        some_integer_array.at(i)
        dbaupp 12y ago
        Has the same problem, we can't support the syntax: let integer: i32 = some_integer_array.at(i); let reference: &i32 = &some_integer_array.at(i); with the desired semantics, without introducing new language concepts. In any case, we did use methods for indexing vectors for a while and it was quite annoying; the shorter syntax is nice.
        frowaway001 12y ago
        I don't think you are getting it.
        scott_s 12y ago
        For the record, dbaupp is on the core team for Rust. But can you explain it to me? Because his explanation makes sense to me: they can't support that syntax, including getting references, without introducing new concepts. How does what your proposing get around introducing those new concepts?
        frowaway001 12y ago
    - frowaway001 12y ago
      That's exactly what I meant with other bad ideas just snowballed on top of it It still baffles me how people can invent two separate ways to invoke something, () and [], and pretend that's a good idea. If they used [] for types, they wouldn't have needed to consider such a bad idea. Now, Rust has to deal with all the random syntax quirks caused by misusing <> for Generics, and it does it pretty badly: As an example, the Foo::<Bar>:: syntax is even worse than Java's Fuz.<Baz>Meth() hack.
      - kibwen 12y ago
        Rust would have needed to do `Foo::[Bar]` anyway in order to deal with the ambiguity surrounding the `[]` operator, as explained in a comment upthread (using `()` instead for indexing is not as simple of a substitution as it seems). In any case, I plan to propose a backwards-compatible extension to Rust's grammar post-1.0 which will make `Foo<Bar>` possible. Finally, I should note that personally I prefer D's syntax for generics, though I'm ambivalent about the particular sigil used (Rust already uses `!` for a fine purpose).

steveklabnik 12y ago

> was made entirely on the basis of familiarity, This is sorta kinda true. A long time ago, Rust used `[]`s. Then, at some point, it changed to `<>`s. When the discussion you're referring to came up, it was determined that there wasn't a good enough reason to switch back to `[]`s, as that also introduced other problems, and so wasn't clearly better, and would introduce a lot of churn.

frowaway001 12y ago
I'd love to know which problems that would have introduced. Rust's choice of <> ignored the lessons from all the language which made that choice before (Java, C#, C++) and from there, other bad ideas just snowballed on top of it.
- steveklabnik 12y ago
  Since it's also used for array access, it introduces another ambiguity in the grammar there.
  - saosebastiao 12y ago
    The ambiguity had a clearly proposed fix in the issue thread: use () for array access. Just like in scala. Lots of people were clamoring for the change, and the only unaddressed opposition to it was from those that explicitly wanted to cater to the c++ familiarity.
    - dbaupp 12y ago
      Using () doesn't work without introducing yet more concepts to the language, to make both let element: i32 = some_integer_array(i); let reference: &i32 = &some_integer_array(i); work. In particular, the second one should give a reference to the element inside the array. I believe Scala doesn't have to deal with this subtlety, since everything is a pointer and generally the precise location of things in memory isn't so important. This issue is definitely not insurmountable, but it is also definitely not a simple direct replacement.
      - frowaway001 12y ago
        some_integer_array.at(i)
        dbaupp 12y ago
        Has the same problem, we can't support the syntax: let integer: i32 = some_integer_array.at(i); let reference: &i32 = &some_integer_array.at(i); with the desired semantics, without introducing new language concepts. In any case, we did use methods for indexing vectors for a while and it was quite annoying; the shorter syntax is nice.
        frowaway001 12y ago
        I don't think you are getting it.
        scott_s 12y ago
        For the record, dbaupp is on the core team for Rust. But can you explain it to me? Because his explanation makes sense to me: they can't support that syntax, including getting references, without introducing new concepts. How does what your proposing get around introducing those new concepts?
        frowaway001 12y ago
  - frowaway001 12y ago
    That's exactly what I meant with other bad ideas just snowballed on top of it It still baffles me how people can invent two separate ways to invoke something, () and [], and pretend that's a good idea. If they used [] for types, they wouldn't have needed to consider such a bad idea. Now, Rust has to deal with all the random syntax quirks caused by misusing <> for Generics, and it does it pretty badly: As an example, the Foo::<Bar>:: syntax is even worse than Java's Fuz.<Baz>Meth() hack.
    - kibwen 12y ago
      Rust would have needed to do `Foo::[Bar]` anyway in order to deal with the ambiguity surrounding the `[]` operator, as explained in a comment upthread (using `()` instead for indexing is not as simple of a substitution as it seems). In any case, I plan to propose a backwards-compatible extension to Rust's grammar post-1.0 which will make `Foo<Bar>` possible. Finally, I should note that personally I prefer D's syntax for generics, though I'm ambivalent about the particular sigil used (Rust already uses `!` for a fine purpose).