3 ms·

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,

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
        For the record, Rasmus Lerdorf is on the core team for PHP. When I said "some_integer_array.at(i)" I certainly didn't mean "rename both things". Alternatively, having one additional magic kind/trait/... to denote "addressable" would be more manageable than shoe-horning things into the language's syntax which can – at this change – not be fixed anymore.
        dbaupp 12y ago
        Yes, I'm absolutely not getting it. You're also not explaining it.
    - deleted 12y ago
      [deleted]
- 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

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
        For the record, Rasmus Lerdorf is on the core team for PHP. When I said "some_integer_array.at(i)" I certainly didn't mean "rename both things". Alternatively, having one additional magic kind/trait/... to denote "addressable" would be more manageable than shoe-horning things into the language's syntax which can – at this change – not be fixed anymore.
        dbaupp 12y ago
        Yes, I'm absolutely not getting it. You're also not explaining it.
  - deleted 12y ago
    [deleted]
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).