28 ms·

Given that: - The cfg style checker accepts a strict superset of the programs that a lexical checker would (so if you're thinking lexically then your thinking

Given that: - The cfg style checker accepts a strict superset of the programs that a lexical checker would (so if you're thinking lexically then your thinking will still work). - The checker is (modulo bugs) sound, so if it thinks a program is valid then it is (so you don't actually have to think deeply about the complex cases if you don't want to). it makes sense that this would be easier to use.

steveklabnik 3y ago
Yes, I think these things are important factors too.
lmm 3y ago
Not necessarily. Imagine a checker that accepted lexically valid programs and also cfg-valid but lexically-invalid programs where the number of lines was odd; such a checker would fulfil your criteria but probably be more difficult to use than a purely lexical checker. IMO Rust has already handicapped their language evolution with NLL and the more complex they make the checker the worse a pit they're going to dig themselves into. As long as it's simple enough to understand it's not too bad, but if we get to the point where people can't reason about the checker there'll be no coming back.
- GolDDranks 3y ago
  > IMO Rust has already handicapped their language evolution with NLL Do you see alternative paths from lexical lifetimes?
  - lmm 3y ago
    I think they should have focused on making lexical lifetimes more usable and lightweight, in a general way that was available to functions rather than just language keywords. Think making it possible to write if/while/for as regular functions in the language - which would also make it possible to write async a lot less painfully, because you'd be able to write your async control flow functions "in userspace". Instead they've chosen to deeply intertwine their particular control flow model with their borrow checker, which means changing or experimenting with those control flow keywords (or introducing new ones) is going to be a lot more costly, and any radical new ideas (whatever the next 10-20 years' equivalent of async is) are going to be much harder to introduce.
    - deleted 3y ago
      [deleted]

steveklabnik 3y ago

Yes, I think these things are important factors too.

lmm 3y ago

Not necessarily. Imagine a checker that accepted lexically valid programs and also cfg-valid but lexically-invalid programs where the number of lines was odd; such a checker would fulfil your criteria but probably be more difficult to use than a purely lexical checker. IMO Rust has already handicapped their language evolution with NLL and the more complex they make the checker the worse a pit they're going to dig themselves into. As long as it's simple enough to understand it's not too bad, but if we get to the point where people can't reason about the checker there'll be no coming back.

GolDDranks 3y ago
> IMO Rust has already handicapped their language evolution with NLL Do you see alternative paths from lexical lifetimes?
- lmm 3y ago
  I think they should have focused on making lexical lifetimes more usable and lightweight, in a general way that was available to functions rather than just language keywords. Think making it possible to write if/while/for as regular functions in the language - which would also make it possible to write async a lot less painfully, because you'd be able to write your async control flow functions "in userspace". Instead they've chosen to deeply intertwine their particular control flow model with their borrow checker, which means changing or experimenting with those control flow keywords (or introducing new ones) is going to be a lot more costly, and any radical new ideas (whatever the next 10-20 years' equivalent of async is) are going to be much harder to introduce.
  - deleted 3y ago
    [deleted]