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.
