Date: Thu, 19 Dec 2024 07:40:05 +0000
> > If you take this logic to the extreme, you should not be allowed to write:
> > if (...) {
> > break;
> > }
> You can't
You can:
while(true)
{
if(true)
{
break;
}
}
But that’s beside the point, it’s a red herring.
The point being that there’s a gap in the ability to properly express intent on how the code should progress, to do something that would otherwise be valid.
Let’s imagine a scenario where the keyword “return” didn’t exist and we had to use “break” instead to prematurely return from a function.
All of a sudden you couldn’t do a premature return from within a while/for/switch.
Someone could still argue: “IMHO, this violates the idea of scope encapsulation. The loop/scope should not know or care what the outer function is doing nor why. And vise-versa. Just because you can does not mean you should.”
But lets be honest; We have all done that!, and we wouldn’t have it any other way.
> > if (...) {
> > break;
> > }
> You can't
You can:
while(true)
{
if(true)
{
break;
}
}
But that’s beside the point, it’s a red herring.
The point being that there’s a gap in the ability to properly express intent on how the code should progress, to do something that would otherwise be valid.
Let’s imagine a scenario where the keyword “return” didn’t exist and we had to use “break” instead to prematurely return from a function.
All of a sudden you couldn’t do a premature return from within a while/for/switch.
Someone could still argue: “IMHO, this violates the idea of scope encapsulation. The loop/scope should not know or care what the outer function is doing nor why. And vise-versa. Just because you can does not mean you should.”
But lets be honest; We have all done that!, and we wouldn’t have it any other way.
Received on 2024-12-19 07:40:10