4 ms·

Well, I was not talking about basic syntactic structure. For eg: take a look at this https://github.com/servo/servo/blob/master/components/constellation/event_l

Well, I was not talking about basic syntactic structure. For eg: take a look at this https://github.com/servo/servo/blob/master/components/constellation/event_loop.rs#L18 https://github.com/servo/servo/blob/master/components/conste... I am not against Rust. Rust has some great ideas and intent. I just feel they should have created simpler syntax. A more complex and unusual syntax doesn't have any real benefits IMO.

naasking 10y ago
You still haven't pointed out what syntax is problematic exactly. I've never programmed in Rust, but I don't have any trouble reading it coming from a C and C# background. What exactly is the problem with the example you linked to?
pcwalton 10y ago
What's the issue with that example?
- naasking 10y ago
  Not having programmed in Rust, the fact that Rust requires all type parameters to be used, thus ruling out proper phantom types, was semantically surprising to me. But I don't understand what syntactic issue the other poster had with that example.
  - steveklabnik 10y ago
    That's what https://doc.rust-lang.org/stable/std/marker/struct.PhantomData.html https://doc.rust-lang.org/stable/std/marker/struct.PhantomDa... is for!
    - naasking 10y ago
      Yes I get it, it just seems unnecessary to require every type parameter to be used. Do you have a link to the discussion motivating this choice?
      - steveklabnik 10y ago
        In my understanding, it has to do with variance. This happened a very long time ago, before 1.0, and so I don't know where the discussion happened, off the top of my head.
        naasking 10y ago
        Found it: https://github.com/rust-lang/rfcs/blob/master/text/0738-variance.md https://github.com/rust-lang/rfcs/blob/master/text/0738-vari... It still seems bizarre to me that a purely type-level expression is forced by an effectively non-existent term. That RFC specifically states that the main problem is that the results of variance inference are largely erased by assuming invariance. That seems like a sensible default for unused type parameters too. It seems from the conclusion of that post that PhantomData only survived because this was the smallest change they had to make to get this all to work better, and because some of this PhantomData could be used for other analyses in the compiler (although it's not clear if better type information could have replaced these uses anyway).

naasking 10y ago

You still haven't pointed out what syntax is problematic exactly. I've never programmed in Rust, but I don't have any trouble reading it coming from a C and C# background. What exactly is the problem with the example you linked to?

pcwalton 10y ago

What's the issue with that example?

naasking 10y ago
Not having programmed in Rust, the fact that Rust requires all type parameters to be used, thus ruling out proper phantom types, was semantically surprising to me. But I don't understand what syntactic issue the other poster had with that example.
- steveklabnik 10y ago
  That's what https://doc.rust-lang.org/stable/std/marker/struct.PhantomData.html https://doc.rust-lang.org/stable/std/marker/struct.PhantomDa... is for!
  - naasking 10y ago
    Yes I get it, it just seems unnecessary to require every type parameter to be used. Do you have a link to the discussion motivating this choice?
    - steveklabnik 10y ago
      In my understanding, it has to do with variance. This happened a very long time ago, before 1.0, and so I don't know where the discussion happened, off the top of my head.
      - naasking 10y ago
        Found it: https://github.com/rust-lang/rfcs/blob/master/text/0738-variance.md https://github.com/rust-lang/rfcs/blob/master/text/0738-vari... It still seems bizarre to me that a purely type-level expression is forced by an effectively non-existent term. That RFC specifically states that the main problem is that the results of variance inference are largely erased by assuming invariance. That seems like a sensible default for unused type parameters too. It seems from the conclusion of that post that PhantomData only survived because this was the smallest change they had to make to get this all to work better, and because some of this PhantomData could be used for other analyses in the compiler (although it's not clear if better type information could have replaced these uses anyway).