7 ms·

Because familiar is not necessarily good. After many decades of use, we have realized that C has many suboptimal syntax decisions.

• saosebastiao 12y ago
  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