vine: overhaul control flow #314
Conversation
There was a problem hiding this comment.
Very nice, lots of good stuff!
Here're my thoughts on the different features:
else for while and for: Very handy, I like it
when: really useful, love it
removal of else if: I don't really like it. Event with the when statement there are still situation where else if is nicer I think (see comments). Does keeping it come at any cost?
let / else match: I like it especially for thinks like errors
no implicit continue in loops: I strongly dislike it. I think the semantics get less intuitive and this is especially bad in loops that are basically while loops but break in the the middle or at the end, e.g. find_primes.vi. One could make the argument that with a mandatory continue at least the compiler would warn you, but I think that would add verbosity. Seeing all the changes there are also already more continues added than breaks removed.
keywords as break target: Quite useful, haven't seen that before but I like it
return, break, continue: As discussed before, solid choice
annotation of return type of control flow structures: Probably very useful in cases where type inference is lost
non-divergence let /else: I'm unsure, for me it's a little too implicit and it sounds somewhat like you're choosing an alternative value for the let assignment.
|
Regarding |
Yeah I think it makes sense to not require an empty arm and only have |
👍
I don't think it's good to have two different constructs that do the same thing; it creates questions of when which should be used, potentially requires converting between them, and makes code written in the language less consistent.
If one has nested conditions to the point that the increased indentation is excessive, a refactor is probably warranted. |
|
I've removed the requirement for the terminal arm in |
loopnow no longer has an implicit continueloop#211whileandforboth supportelseblocks, which allow them to evaluate to a valuewhile/else#266()or{}are now no longer passed between stageswhile/elseandfor/elsechange added a number of()-type variables, so this optimization was necessary to not regress performance for thesebreakandcontinuesupport specifying a keyword to break, instead of a label (e.g.break.do), making a lot of labels unnecessarywhenexpressionswhenexpression #226else ifconstruct; one can instead use awhenor add braces around theiflet/elseno longer requires that the else block explicitly divergeslet/else matchlet/else match#297return/break/continuestatementsreturn/break/continuestatements #259Likely easiest to review commit-by-commit, as there are a lot of changes here.