On 13 June 2013 20:18, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Thu, Jun 13, 2013 at 11:50:49AM -0700, Brad Roberts wrote:
>>
>> I think it should be illegal, but not because it's a catch block but because of the initialization.  If the catch was just "catch (Exception)" then it shouldn't be illegal.
>
> Why shouldn't it be illegal, though? I honestly don't see any use case for such a strange construct. Not to mention, like monarch_dodra said, if the anonymous Exception's reference is on the stack, then at the end of the catch block there'd be code to adjust the stack pointer, which will trash your stack pointer horribly if we goto the middle of the block bypassing the stack allocation of the Exception reference.
>

Thank goodness D's exceptions are all heap allocated!

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 13 June 2013 20:08, monarch_dodra <monarchdodra@gmail.com> wrote:
> On Thursday, 13 June 2013 at 18:51:01 UTC, Brad Roberts wrote:
>>
>> On 6/13/13 10:35 AM, Iain Buclaw wrote:
>>
>> I think it should be illegal, but not because it's a catch block but
>> because of the initialization.
>>  If the catch was just "catch (Exception)" then it shouldn't be illegal.
>
>
> Again for what it's worth, the C++ program with "catch(...)" also fails.
>
> Even if the variable is unnamed though, doesn't the code still cross the declaration, which is enough to make a mess of things? I mean, the caught exception is still on the stack somewhere, right?
>
> And still, if, by some hoops, we could make it work, do we really want to add that functionality? I mean, would it really even be useful?
>
> That, and I'm not a fan to having code that breaks just because you later decided to name a variable.
>
> Eg:
> before:
> catch(Exception) //OK
> after
> catch(Exception e) //Nope, that's illegal now. Good luck finding out why!


Well, a good error message will do well in that case.

Currently, gdc has the following stock errors:

    "cannot goto into catch block"

Which is indeed confusing if anonymous catches are allowed to bypass this check.  What I would instead do (once I have the scan for skipped initialisations complete) is have a more meaningful, and generic:

    "goto to label 'L2' skips initialisation of 'Exception e'"


Ditto for any other forms of jumps over any other local variable declarations.


Regards
--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 13 June 2013 at 20:40:27 UTC, Iain Buclaw wrote:
> On 13 June 2013 20:18, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> On Thu, Jun 13, 2013 at 11:50:49AM -0700, Brad Roberts wrote:
>>>
>>> I think it should be illegal, but not because it's a catch block but
>>> because of the initialization.  If the catch was just "catch
>>> (Exception)" then it shouldn't be illegal.
>>
>> Why shouldn't it be illegal, though? I honestly don't see any use case
>> for such a strange construct. Not to mention, like monarch_dodra said,
>> if the anonymous Exception's reference is on the stack, then at the end
>> of the catch block there'd be code to adjust the stack pointer, which
>> will trash your stack pointer horribly if we goto the middle of the
>> block bypassing the stack allocation of the Exception reference.
>>
>
> Thank goodness D's exceptions are all heap allocated!
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';

Irrelevant no? You're still throwing around your pointer, which takes its stack space.

Well, I guess as long as the compiler (optionally) supports skipping over initialization it means it can handle the magic required to maintain the stack pointer, so that shouldn't really be a problem.

On 6/13/13 12:22 PM, Iain Buclaw wrote:
> On Thursday, 13 June 2013 at 18:51:01 UTC, Brad Roberts wrote:
>> On 6/13/13 10:35 AM, Iain Buclaw wrote:
>>> Can someone remind me again what was last agreed when I brought this up?
>>>
>>> I seem to recall that this should be disallowed as is practically always a bug, also, and it skips
>>> any initialisation of the exception object. (See: http://dlang.org/statement.html - "It is illegal
>>> for a GotoStatement to be used to skip initializations.")
>>>
>>> Current failing test I want to have removed from the test suite.
>>>
>>> test/runnable/eh.d:
>>> void test8()
>>> {
>>>   int a;
>>>   goto L2;    // gdc Error: cannot goto into catch block
>>>
>>>   try {
>>>       a += 2;
>>>   }
>>>   catch (Exception e) {
>>>       a += 3;
>>> L2: ;
>>>       a += 100;
>>>   }
>>>   assert(a == 100);
>>> }
>>>
>>>
>>> Thanks
>>> Iain.
>>
>> I think it should be illegal, but not because it's a catch block but because of the initialization.
>>  If the catch was just "catch (Exception)" then it shouldn't be illegal.
>
> This could be easily possible to do, and still keep 100% safe. But I must still ask why why why,
> Delilah, would you do that?

Oh, just minimizing what's illegal.  _I_ wouldn't do that.

On 13 June 2013 23:53, Brad Roberts <braddr@puremagic.com> wrote:
> On 6/13/13 12:22 PM, Iain Buclaw wrote:
>>
>> On Thursday, 13 June 2013 at 18:51:01 UTC, Brad Roberts wrote:
>>>
>>> On 6/13/13 10:35 AM, Iain Buclaw wrote:
>>>>
>>>> Can someone remind me again what was last agreed when I brought this up?
>>>>
>>>> I seem to recall that this should be disallowed as is practically always
>>>> a bug, also, and it skips
>>>> any initialisation of the exception object. (See:
>>>> http://dlang.org/statement.html - "It is illegal
>>>> for a GotoStatement to be used to skip initializations.")
>>>>
>>>> Current failing test I want to have removed from the test suite.
>>>>
>>>> test/runnable/eh.d:
>>>> void test8()
>>>> {
>>>>   int a;
>>>>   goto L2;    // gdc Error: cannot goto into catch block
>>>>
>>>>   try {
>>>>       a += 2;
>>>>   }
>>>>   catch (Exception e) {
>>>>       a += 3;
>>>> L2: ;
>>>>       a += 100;
>>>>   }
>>>>   assert(a == 100);
>>>> }
>>>>
>>>>
>>>> Thanks
>>>> Iain.
>>>
>>>
>>> I think it should be illegal, but not because it's a catch block but
>>> because of the initialization.
>>>  If the catch was just "catch (Exception)" then it shouldn't be illegal.
>>
>>
>> This could be easily possible to do, and still keep 100% safe. But I must
>> still ask why why why,
>> Delilah, would you do that?
>
>
> Oh, just minimizing what's illegal.  _I_ wouldn't do that.

OK, and just out of curiosity, what's your view on jumps into try statement blocks?

goto L2;

try {
  /* ... */
L2:
  /* ... */
}


Obviously the same rule must apply if the jump to the label skips over any initialisations at the beginning of the try block above it...

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 6/13/2013 3:53 PM, Brad Roberts wrote:
> Oh, just minimizing what's illegal.  _I_ wouldn't do that.

[Looks down, rubs toe in dirt.]

On 6/13/2013 2:08 PM, monarch_dodra wrote:
> Well, I guess as long as the compiler (optionally) supports skipping over
> initialization it means it can handle the magic required to maintain the stack
> pointer, so that shouldn't really be a problem.

Sometimes it is handy to skip initializations, and I get annoyed with g++ barfs on me doing that. That said, such should only be allowed in @system code.

On a related note, doing a goto into a finally block is pretty problematic to support because it's actually a mini-function.

On 14 June 2013 19:44, Walter Bright <newshound2@digitalmars.com> wrote:
> On 6/13/2013 2:08 PM, monarch_dodra wrote:
>>
>> Well, I guess as long as the compiler (optionally) supports skipping over
>> initialization it means it can handle the magic required to maintain the
>> stack
>> pointer, so that shouldn't really be a problem.
>
>
> Sometimes it is handy to skip initializations, and I get annoyed with g++ barfs on me doing that. That said, such should only be allowed in @system code.
>

IMO, the only annoying ones in C++ are where switch statements jumping to case labels crosses initialisation of variables, but D solves that by having cases in their own scope. :o)

Any other type of skipped initialisation is an error that should definitely have all alarm bells ringing.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 06/14/2013 08:44 PM, Walter Bright wrote:
> On 6/13/2013 2:08 PM, monarch_dodra wrote:
>> Well, I guess as long as the compiler (optionally) supports skipping over
>> initialization it means it can handle the magic required to maintain
>> the stack
>> pointer, so that shouldn't really be a problem.
>
> Sometimes it is handy to skip initializations, and I get annoyed with
> g++ barfs on me doing that. That said, such should only be allowed in
> @system code.
>
> On a related note, doing a goto into a finally block is pretty
> problematic to support because it's actually a mini-function.

In the worst case, duplicate some code.