Is this a bug? +goto

[Michelle Long]

On Thursday, 8 November 2018 at 06:56:14 UTC, Jonathan M Davis 
wrote:
> On Wednesday, November 7, 2018 10:50:29 PM MST Michelle Long 
> via Digitalmars-d-learn wrote:
>> On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis
>>
>> wrote:
>> > On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long 
>> > via
>> >
>> > Digitalmars- d-learn wrote:
>> >> Don't let their psychobabble fool you. They are wrong and 
>> >> you were right from the start.
>> >
>> > ...
>> >
>> >> Case A:
>> >> {
>> >>
>> >>     if (true) goto X;
>> >>     int x;
>> >>
>> >> }
>> >> X:
>> >>
>> >>
>> >> Case B:
>> >> {
>> >>
>> >>     if (true) goto X;
>> >>     {
>> >>
>> >>        int x;
>> >>
>> >>     }
>> >>
>> >> }
>> >> X:
>> >>
>> >>
>> >> These two cases are EXACTLY the same semantically. It's like
>> >> writing A + B and (A + B).
>> >
>> > That's not the situation that the OP was describing. If 
>> > adding braces in a situation where the braces have no 
>> > semantic effect has any impact on goto, then it's a compiler 
>> > bug. It's adding a new scope that affects the lifetime of a 
>> > variable whose declaration is being jumped over by a goto 
>> > that matters.
>> >
>> > I know that you're frustrated, because you've hit a problem 
>> > with goto in complex code, and you don't have a simple 
>> > example that shows the compiler bug, but the approach that D 
>> > takes with goto (and any construct that potentially requires 
>> > code flow analysis) of avoiding requiring that the compiler 
>> > be smart is precisely to reduce the risk of there being 
>> > cases where the compiler is going to screw it up in complex 
>> > code even though it gets it right in the simple cases. If 
>> > the language required the compiler to be smart about such 
>> > things, we'd have a lot more problems with subtle, hard to 
>> > track down compiler bugs in complex code. So, we'd just have 
>> > _more_ cases where people would be hitting frustrating bugs 
>> > like you are.
>>
>> That's fine. The D compiler writers can decide to do whatever 
>> they want. I can simply take my "business" elsewhere if I 
>> don't like it.
>>
>> What I am talking about is about an obvious error(Ok, I 
>> haven't produced a simplified test case but dustmite or visual 
>> D is not working for me to do so at this point in time, but it 
>> would be nice for sake of argument to assume I'm right...).
>>
>> > Regardless, if you want to actually have your problem fixed, 
>> > you're going to need to provide a reproducible test case in 
>> > a bugzilla report, even if it's large, otherwise no one is 
>> > going to be able to track it down for you.
>>
>> That's easier said than done. I wasn't expecting anyone to be 
>> able to fix a bug that can't be reproduced.
>>
>> What I expect is that, given my assumptions that I'm right, 
>> that people can agree the compiler does have a bug or flaw 
>> that can easily be fixed give then two simplified test cases 
>> basic purely what I have done in my own code.
>>
>> 1.
>>
>> foreach(...)
>> {
>>    if (x) goto Y:
>>    int z;
>> }
>> Y:
>>
>> Fails.
>>
>> foreach(...)
>> {
>>    if (x) goto Y:
>>    {
>>       int z;
>>    }
>> }
>> Y:
>>
>> Passes.
>>
>> THAT IS FACT! It doesn't matter if the examples work above. I 
>> have simplified what I have done and in my code I simply add 
>> brackets and it works! That is what people should be thinking 
>> about... not test cases, MWE's, compiler versions, etc.
>>
>> Is it logical that the compiler **should** error out in the 
>> first case and no in the second?
>>
>> That is what the discussion is ALL about. Once that is dealt 
>> with then we can move on to finding out more specifics. There 
>> is no reason to build the windows of a house before the 
>> foundation, it's just far more work without any benefit.
>>
>>
>> Once people can say: If that is all you are doing is adding 
>> brackets around what follows the goto and break out of 
>> scope(which is what the code above says) and you can compile, 
>> then it is a compiler bug or flaw.
>>
>> Once people verify that, rather than trying to create rabbit 
>> holes, then I can do more work on finding out more specifics. 
>> Until then, it is pointless to do anything on my side because 
>> if people come back and say "No, it is suppose to work that 
>> way" then what the hell am I trying to simplify and fix? It's 
>> not a bug then.
>
> If you have code where you get a compiler error about a goto 
> skipping the initializiation of a variable, and you add braces 
> that should have no semantic effect on the code whatsoever, and 
> the error goes away, then yes, that's a compiler bug. If, 
> however, the braces do affect the semantics of the code, then 
> that's not necessarily a compiler bug. At that point, whether 
> it's a compiler bug or not would depend on what exactly the 
> code was.
>
> In an example such as
>
> while(1)
> {
>     if(cond)
>         goto label;
>     int x;
> }
> label:
>
> adding braces such as
>
> while(1)
> {
>     if(cond)
>     {
>         goto label;
>     }
>     int x;
> }
> label:
>
> or
>
> while(1)
> {
>     if(cond)
>         goto label;
>     {
>         int x;
>     }
> }
> label:
>
> should have no effect. However, in an example such as
>
> goto label;
> int x;
> label:
>
> adding braces such as
>
> goto label;
> {
>     int x;
> }
> label:
>
> changes the code entirely.

Obviously, but that is not the case I mentioned. You can assume 
that I know how scopes work. No need to assume everyone that 
shows two cases that you have to bring up an unrelated case as a 
potential cause unless it is relevant.

Remember, I'm showing the starting case that has the bug and the 
final case that doesn't... it is simply "mental dustmite" on the 
code I have.

You shouldn't assume everyone can't comprehend such trivialities.

If a person cannot understand scope then I doubt they understand 
goto's... and definitely not that adding braces should not change 
the compiler behavior.

What happens when you do that you just create noise that makes it 
more difficult to have a proper discussion that gets at the whole 
point of the conversation.

You seem to default to assuming that the person you are talking 
to has no clue about the problem at hand. You might not do it 
intentionally but it is wrong to assume that because it almost 
never helps.