> Incidentally, I recently posted in another thread here how I just discovered the 'named loop/scope feature, and how I thought it was great, but took a while to discover. A reply was along the effect of "That's not new; it's a common feature". Maybe I don't really know rust, but a dialect of it...
I assume I'm the one who taught you this, and for the edification of others, you can do labeled break not only in Rust, but also C#, Java, and JavaScript. An even more powerful version of function-local labels and break/continue/goto is available in Go (yes, in Go!), and a yet more powerful version is in C and C++.
The point being, the existence of obscure features does not a large or complex language make, unless you're willing to call Go a large and complex language. By this metric, anyone who's never used a goto in Go is using a dialect of Go, which would be silly; just because you've never had cause to use a feature of a language does not a dialect make.
Coming from 14 years of Perl, and dabbling in Perl 6, I don’t consider Rust a “large language”… but like Perl (and to an extent C++) I do find people craft their own dialects over time via osmosis.
And I don’t see anything bad about this!
After 11 years of full-time Rust, I have never needed to use Pin once, and it’s only having to do FFI have I even had to reach for unsafe.
Unless you memorise the Rust Reference Manual and constantly level up with each release, you’ll never “know” the whole language… but IMHO this shouldn’t stop you from enjoying your small self-dialect - TMTOWTDI!
>And I don’t see anything bad about this!
As someone else who has learned (and forgotten) a great deal of Perl and C++ arcana: The badness is that it makes it harder for one person to understand another person's code.
Wow, I had no idea JavaScript has labeled break! Thanks for the comment.
It's a terrible feature, really. If you need a labeled break what you really need is more decomposition. I'm pretty sure that Dijkstra would have written a nice article about it, alas, he is no longer with us.
I doubt he would, goto heavy code really jumped all over the place in incomprehensible manners. Labelled break/goto is used in perhaps 1% of loops due to actually implementing some algorithm that would've needed extra flags,etc. and EVEN THEN don't break the scoped readability.
There's a huge difference between reining in real world chaos vs theoretical inelagancies (ESPECIALLY if fixing that would introduce other complexity to work around the lack of it).
It depends on how big or trivial the loops you need are. If they're only 3 or 4 lines, extracting their body into a function doesn't improve anything.
Dijkstra was wrong on this one. Breaks and continues help to keep the code more readable by reducing the amount of state that needs to be tracked.
Yes, from the purely theoretical standpoint, you can always rewrite the code to use flags inside the loop conditions. And it even allows formal analysis by treating this condition as a loop invariant.
But that's in theory. And we all know the difference between the theory and practice.
Dijkstra did not say anything about "break" and "continue".
Moreover, "continue" has been invented only in 1974, as one of the few novel features of the C programming language, some years after the Dijkstra discussion.
Both simple "break" and "continue" are useful, because unlike "goto" they do not need labels, yet the flow of control caused by them is obvious.
Some languages have versions of "break" and "continue" that can break or continue multiple nested loops. In my opinion, unlike simple "break" and "continue" the multi-loop "break" and "continue" are worse than a restricted "goto" instruction. The reason is that they must use labels, exactly like "goto", but the labels are put at the beginning of a loop, far away from its end , which makes difficult to follow the flow of control caused by them, as the programmer must find first where the loop begins, then search for its end. Therefore they are definitely worse than a "goto".
Instead of having multi-loop break and continue, it is better to have a restricted "goto", which is also useful for handling errors. Restricted "goto" means that it can jump only forwards, not backwards, and that it can only exit from blocks, not enter inside blocks.
These restrictions eliminate the problems caused by "goto" in the ancient non-structured programming languages, which were rightly criticized by Dijkstra.