Can't you use scope guards for that too? Those work for any scope, not only function scope.

On Tuesday, 1 October 2013 at 12:46:50 UTC, Dicebot wrote:
> Can't you use scope guards for that too? Those work for any scope, not only function scope.

I hadn't thought of that before, but I don't think so. scope guards are designed to run a specific piece of code, no mater the code path.

What I mostly want to do is just break out of a "control block".

Either that, or I'm being retarded...?

On Tuesday, 1 October 2013 at 11:22:12 UTC, Chris wrote:
> Sometimes goto is simply the best and most efficient solution within a code block (to avoid code duplication, unnecessary checks or redirecting to yet another function blah blah).

News to me! I haven't used goto in 15 years of development as there are always more elegant ways of designing software.

The only reason i can see goto being properly used is in machine generated code where no developer will be maintaining it.

On Tuesday, 1 October 2013 at 13:02:56 UTC, monarch_dodra wrote:
> On Tuesday, 1 October 2013 at 12:46:50 UTC, Dicebot wrote:
>> Can't you use scope guards for that too? Those work for any scope, not only function scope.
>
> I hadn't thought of that before, but I don't think so. scope guards are designed to run a specific piece of code, no mater the code path.
>
> What I mostly want to do is just break out of a "control block".
>
> Either that, or I'm being retarded...?

In that case you can always replace "control block + goto" with nested function + return + scope guard inside it (if some cleanup code needs to be run) unless I am missing something.

(I think your snippet misses actual labels so it was unclear:))

On Tuesday, 1 October 2013 at 12:13:18 UTC, Dicebot wrote:
> On Tuesday, 1 October 2013 at 11:35:35 UTC, Chris wrote:
>> Thanks, this is what I was looking for, a more elegant solution. I was going through some old code and saw the odd goto statement. scope() shows of course that some sort of goto mechanism is pretty handy (no matter what the textbooks say).
>
> goto is not avoided because of functionality it enables but because of unhygienic way it is implemented. scope guards offer part of that functionality in much more clean and safe way and there is nothing wrong about using them.

That was my point.

On Tuesday, 1 October 2013 at 11:40:35 UTC, Manu wrote:
> On 1 October 2013 21:22, Chris <wendlec@tcd.ie> wrote:
>
>> Just a short question. Usually goto statements are frowned upon as being
>> bad programming style (in textbooks at least). D has it (thankfully) and
>> I've used it, albeit sparingly. Sometimes goto is simply the best and most
>> efficient solution within a code block (to avoid code duplication,
>> unnecessary checks or redirecting to yet another function blah blah). Is it
>> ok or even necessary to use goto in D? Or does the compiler recognize
>> _obvious_ cases and generate code accordingly? For example would it turn
>> something like this
>>
>> // ...
>> if (word.length == 1) {
>>  // format output
>>  return output;
>> } else if (word.length > 1) {
>>   // do some additional processing
>>   // format output
>>   return output;
>> }
>>
>> into
>>
>> // ...
>> if (word.length == 1) goto FormatOutput;
>>
>> // if word.length > 1, some extra work has to be done
>> // initialize some variables, parse, do some processing etc.
>>
>> FormatOutput:
>>  // .....
>>
>> return output;
>>
>
> Well, obviously that should be rewritten:
>
>   if (word.length > 1)
>   {
>     // additional processing
>   }
>   // format output
>   return output;

> Note: there's an un-handled case in your example, but I'll ignore that.

That was just a made up example (of an obvious case). The real case was a bit more complicated (involving an associative array).

> Anyway, goto is supported. Walter likes it. I use it from time to time.
> I'd say 90% of the time I find goto useful is when I need to bail from
> nested loops. I've often wondered if something like break(2) would be a
> more elegant solution to the breaking out of nested loops problem.
>
> But in direct answer to your question, I think you'll find modern
> optimisers are smart enough to make the optimisation you are looking for. I
> haven't tested that precise case, but I've definitely expected the
> optimiser to do the right thing in similar cases, and it does. I rarely
> write code that requires me to have faith in any optimiser though.

Sure, but it's good to know that some sub-optimal code is optimized, until I find the time to optimize it by hand. Optimizing too early can be more harmful than sub-optimal code (that is just a wee bit slower but harmless).

On Tuesday, 1 October 2013 at 13:09:01 UTC, Dicebot wrote:
> On Tuesday, 1 October 2013 at 13:02:56 UTC, monarch_dodra wrote:
>> On Tuesday, 1 October 2013 at 12:46:50 UTC, Dicebot wrote:
>>> Can't you use scope guards for that too? Those work for any scope, not only function scope.
>>
>> I hadn't thought of that before, but I don't think so. scope guards are designed to run a specific piece of code, no mater the code path.
>>
>> What I mostly want to do is just break out of a "control block".
>>
>> Either that, or I'm being retarded...?
> (I think your snippet misses actual labels so it was unclear:))

Right, sorry.

> In that case you can always replace "control block + goto" with nested function + return + scope guard inside it (if some cleanup code needs to be run) unless I am missing something.

I was going to say: "but using functions is a pain when you have variables that are in scope you need to reuse", but I keep forgetting that D can indeed nest functions.

The only "limitation" of using a nested function, as opposed to a "breakable block", is that can't move code into a nested function, if it contains a (conditional) return.

I guess the conclusion is that each code snippet is unique. With enough effort, you can probably eliminate goto from almost any example. I do find that sometimes, you tend to have to jump through hoops for that tough, and the final code is not necessarily "better" either.

On Tuesday, 1 October 2013 at 11:40:35 UTC, Manu wrote:
> Note: there's an un-handled case in your example, but I'll ignore that.
> Anyway, goto is supported. Walter likes it. I use it from time to time.
> I'd say 90% of the time I find goto useful is when I need to bail from
> nested loops. I've often wondered if something like break(2) would be a
> more elegant solution to the breaking out of nested loops problem.
>

BreakableLoop: while(condition) {
    while(condition) {
        // Stuff . . .
        break BreakableLoop;
    }
}

Also works with continue.

Manu píše v Út 01. 10. 2013 v 21:40 +1000:


> I'd say 90% of the time I find goto useful is when I need to bail from nested loops. I've often wondered if something like break(2) would be a more elegant solution to the breaking out of nested loops problem.

I use break SomeLabel for this situations:

FirstLoop: while(1)
{
    SecondLoop: while(1)
    {
        break FirstLoop;
    }
}

On 1 October 2013 23:54, deadalnix <deadalnix@gmail.com> wrote:

> On Tuesday, 1 October 2013 at 11:40:35 UTC, Manu wrote:
>
>> Note: there's an un-handled case in your example, but I'll ignore that. Anyway, goto is supported. Walter likes it. I use it from time to time. I'd say 90% of the time I find goto useful is when I need to bail from nested loops. I've often wondered if something like break(2) would be a more elegant solution to the breaking out of nested loops problem.
>>
>>
> BreakableLoop: while(condition) {
>     while(condition) {
>         // Stuff . . .
>         break BreakableLoop;
>     }
> }
>
> Also works with continue.
>

... O_O

Is this D code?
I've never seen that. If that works, that's awesome!