This should not be an error when the goto jumps outside the current block!

{
   goto Y;
   int x;
}
Y:

There is no chance of any local variable being used. This makes it impossible to use goto statements in any reasonable way without littering the code with brackets.

On 29/10/2018 4:22 PM, Michelle Long wrote:
> This should not be an error when the goto jumps outside the current block!
> 
> {
>     goto Y;
>     int x;
> }
> Y:
> 
> There is no chance of any local variable being used. This makes it impossible to use goto statements in any reasonable way without littering the code with brackets.
> 

Compiles + runs:

import std.stdio;

void main() {
    {
        goto Y;
        int x;
        writeln("booo", x);
    }
    Y:
    writeln("Hello D");
}

Going to need a more complete example.

On Monday, 29 October 2018 at 03:24:35 UTC, rikki cattermole wrote:
> On 29/10/2018 4:22 PM, Michelle Long wrote:
>> This should not be an error when the goto jumps outside the current block!
>> 
>> {
>>     goto Y;
>>     int x;
>> }
>> Y:
>> 
>> There is no chance of any local variable being used. This makes it impossible to use goto statements in any reasonable way without littering the code with brackets.
>> 
>
> Compiles + runs:
>
> import std.stdio;
>
> void main() {
>     {
>         goto Y;
>         int x;
>         writeln("booo", x);
>     }
>     Y:
>     writeln("Hello D");
> }
>
> Going to need a more complete example.

The problem is when you remove the brackets.

@OP

I don't see what you expect the compiler to do? You're skipping the declaration and usage of it so what's the point?

D is not Javascript and has no concept of hoisting.

On Tuesday, 30 October 2018 at 06:37:22 UTC, Bauss wrote:
> On Monday, 29 October 2018 at 03:24:35 UTC, rikki cattermole wrote:
>> On 29/10/2018 4:22 PM, Michelle Long wrote:
>>> This should not be an error when the goto jumps outside the current block!
>>> 
>>> {
>>>     goto Y;
>>>     int x;
>>> }
>>> Y:
>>> 
>>> There is no chance of any local variable being used. This makes it impossible to use goto statements in any reasonable way without littering the code with brackets.
>>> 
>>
>> Compiles + runs:
>>
>> import std.stdio;
>>
>> void main() {
>>     {
>>         goto Y;
>>         int x;
>>         writeln("booo", x);
>>     }
>>     Y:
>>     writeln("Hello D");
>> }
>>
>> Going to need a more complete example.
>
> The problem is when you remove the brackets.
>
> @OP
>
> I don't see what you expect the compiler to do? You're skipping the declaration and usage of it so what's the point?
>
> D is not Javascript and has no concept of hoisting.

You take examples WAY to literal. Sheesh, do you really think life is that simple? Do you need every detail spelled out for things to make sense?

foreach(x; Y)
{
    if (something or another which I won't spell out no matter how much you cry)
        goto Q; // compiler complains here about x
    int x;
}
Q:

There is no reason why the compiler should have a problem with this.. the fact that using brackets around int x; satisfies the compiler proves this.

On Tuesday, 30 October 2018 at 21:21:22 UTC, Michelle Long wrote:
> There is no reason why the compiler should have a problem with this.. the fact that using brackets around int x; satisfies the compiler proves this.

It doesn't have a problem with that?
https://run.dlang.io/is/YRapyT

Also, if you're jumping out of a scope, most of the time a (labeled) break suffices. I suppose in your actual code, you skip to somewhere further than the first statement after the current block?

On Tuesday, 30 October 2018 at 21:21:22 UTC, Michelle Long wrote:
>
> You take examples WAY to literal. Sheesh, do you really think life is that simple? Do you need every detail spelled out for things to make sense?
>
> foreach(x; Y)
> {
>     if (something or another which I won't spell out no matter how much you cry)
>         goto Q; // compiler complains here about x
>     int x;
> }
> Q:
>
> There is no reason why the compiler should have a problem with this.. the fact that using brackets around int x; satisfies the compiler proves this.


struct Magic
{
    ~Magic()
    {
        writeln("blah");
    }
]

void test()
{
    if(cond)
        goto Y;

    Magic magic;

    Y:
    writeln("stuff");

    // calls ~Magic();
}

You'd need a bunch of extra information to know what is and wasn't actually declared and initialized.

"Putting brackets around it proves it".

void test()
{
    if(cond)
        goto Y;

    {
        Magic magic;

        // calls ~Magic();
    }

    Y:
    writeln("stuff");

}

There is no more conflict with brackets, yes. But expecting the compiler to do this changes the behavior of the code. Sure if there's no destructor it could work around it, but it would complicated code generation. Adding a bunch of time looking for these circumstances.

It's just not worth it, use brackets like you are now or move the declarations of your variables up to the top of the scope before any gotos. Pretty simple workarounds.

On Tuesday, 30 October 2018 at 06:37:22 UTC, Bauss wrote:
>
> D is not Javascript and has no concept of hoisting.

Neither is C.

--------------

#include <stdio.h>

int main()
{
    // In C, depending on your warning settings, you might get
    // an 'unreachable' code warning when you compile.
    // D however, treats the code as an 'error', and won't compile it...
    // unless you add those extra braces.
    // in my view, it should at most be a 'warning', not an 'error'.
    // trust the programmer!

    //{
        goto Y;
        int x;
        printf("%d",x);
    //}

Y:
    puts("Hello");
}

--------------

On Tuesday, 30 October 2018 at 06:37:22 UTC, Bauss wrote:
>
> D is not Javascript and has no concept of hoisting.

C is not javascript either...

int main()
{
  goto Y;
  puts("you will not see this");

Y:
  puts("Hello D");

  return 0;
}


// so.. as first asked, why does D require you to put in extra brackets?

On Tuesday, 30 October 2018 at 23:31:46 UTC, luckoverthere wrote:
> On Tuesday, 30 October 2018 at 21:21:22 UTC, Michelle Long wrote:
>>
>> You take examples WAY to literal. Sheesh, do you really think life is that simple? Do you need every detail spelled out for things to make sense?
>>
>> foreach(x; Y)
>> {
>>     if (something or another which I won't spell out no matter how much you cry)
>>         goto Q; // compiler complains here about x
>>     int x;
>> }
>> Q:
>>
>> There is no reason why the compiler should have a problem with this.. the fact that using brackets around int x; satisfies the compiler proves this.
>
>
> struct Magic
> {
>     ~Magic()
>     {
>         writeln("blah");
>     }
> ]
>
> void test()
> {
>     if(cond)
>         goto Y;
>
>     Magic magic;
>
>     Y:
>     writeln("stuff");
>
>     // calls ~Magic();
> }
>
> You'd need a bunch of extra information to know what is and wasn't actually declared and initialized.
>
> "Putting brackets around it proves it".
>
> void test()
> {
>     if(cond)
>         goto Y;
>
>     {
>         Magic magic;
>
>         // calls ~Magic();
>     }
>
>     Y:
>     writeln("stuff");
>
> }
>
> There is no more conflict with brackets, yes. But expecting the compiler to do this changes the behavior of the code. Sure if there's no destructor it could work around it, but it would complicated code generation. Adding a bunch of time looking for these circumstances.
>
> It's just not worth it, use brackets like you are now or move the declarations of your variables up to the top of the scope before any gotos. Pretty simple workarounds.


You are not understanding the problem. The goto must be in the same scope as the local variable:

{

   goto Y;
   int x;
}
Y:

The compiler will complain(I'm doing it in a foreach loop) that x is skipped!!!

Do you understand?

The goto will always bypass x being declared so it doesn't matter. The compiler may optimize out the simple case above, but that is irrelevant to the problem.

The problem is simple: The compiler thinks that the declared variables are used after the goto but it is impossible since the goto skips out of the block and the local variables cease to exist.

The compiler treats the problem as if it is

{
    goto Y:
    int x;
    Y:
}

and that is a totally different problem. They are not the same but the compiler treats them the same.

In the second case the goto does skip over the declaration, in the first case it does not. In the second case it is a problem but in the first case it cannot be.

Again, adding the brackets proves it.

On Saturday, 3 November 2018 at 03:52:12 UTC, Michelle Long wrote:
> On Tuesday, 30 October 2018 at 23:31:46 UTC, luckoverthere wrote:
>> On Tuesday, 30 October 2018 at 21:21:22 UTC, Michelle Long wrote:
>>>
>>> You take examples WAY to literal. Sheesh, do you really think life is that simple? Do you need every detail spelled out for things to make sense?
>>>
>>> foreach(x; Y)
>>> {
>>>     if (something or another which I won't spell out no matter how much you cry)
>>>         goto Q; // compiler complains here about x
>>>     int x;
>>> }
>>> Q:
>>>
>>> There is no reason why the compiler should have a problem with this.. the fact that using brackets around int x; satisfies the compiler proves this.
>>
>>
>> struct Magic
>> {
>>     ~Magic()
>>     {
>>         writeln("blah");
>>     }
>> ]
>>
>> void test()
>> {
>>     if(cond)
>>         goto Y;
>>
>>     Magic magic;
>>
>>     Y:
>>     writeln("stuff");
>>
>>     // calls ~Magic();
>> }
>>
>> You'd need a bunch of extra information to know what is and wasn't actually declared and initialized.
>>
>> "Putting brackets around it proves it".
>>
>> void test()
>> {
>>     if(cond)
>>         goto Y;
>>
>>     {
>>         Magic magic;
>>
>>         // calls ~Magic();
>>     }
>>
>>     Y:
>>     writeln("stuff");
>>
>> }
>>
>> There is no more conflict with brackets, yes. But expecting the compiler to do this changes the behavior of the code. Sure if there's no destructor it could work around it, but it would complicated code generation. Adding a bunch of time looking for these circumstances.
>>
>> It's just not worth it, use brackets like you are now or move the declarations of your variables up to the top of the scope before any gotos. Pretty simple workarounds.
>
>
> You are not understanding the problem. The goto must be in the same scope as the local variable:
>
> {
>
>    goto Y;
>    int x;
> }
> Y:
>
> The compiler will complain(I'm doing it in a foreach loop) that x is skipped!!!
>
> Do you understand?
>
> The goto will always bypass x being declared so it doesn't matter. The compiler may optimize out the simple case above, but that is irrelevant to the problem.
>
> The problem is simple: The compiler thinks that the declared variables are used after the goto but it is impossible since the goto skips out of the block and the local variables cease to exist.
>
> The compiler treats the problem as if it is
>
> {
>     goto Y:
>     int x;
>     Y:
> }
>
> and that is a totally different problem. They are not the same but the compiler treats them the same.
>
> In the second case the goto does skip over the declaration, in the first case it does not. In the second case it is a problem but in the first case it cannot be.
>
> Again, adding the brackets proves it.


The problem you describe doesn't exist.

https://run.dlang.io/is/Snpt3l

If that isn't the issue, then actually give a runable source example with the associated error that it produces.