http://wiki.dlang.org/DIP65

tldr: There are parser and specification bugs and I want to fix them. It will break some poorly-written code, but I think I can automate the upgrade process.

On 7/8/2014 2:31 PM, Brian Schott wrote:
> http://wiki.dlang.org/DIP65
>
> tldr: There are parser and specification bugs and I want to fix them. It will
> break some poorly-written code, but I think I can automate the upgrade process.

I don't want to break existing code. The grammar ambiguity issue can be resolved by the user as:

catch (A) { .someFunction(); }

On Wednesday, 9 July 2014 at 02:48:03 UTC, Walter Bright wrote:
> On 7/8/2014 2:31 PM, Brian Schott wrote:
>> http://wiki.dlang.org/DIP65
>>
>> tldr: There are parser and specification bugs and I want to fix them. It will
>> break some poorly-written code, but I think I can automate the upgrade process.
>
> I don't want to break existing code. The grammar ambiguity issue can be resolved by the user as:
>
> catch (A) { .someFunction(); }

There is no ambiguity in the grammar. "catch (A) { ... }" is not valid. The spec requires that you give the exception a name. A spec compliant D compiler MUST parse your example code with the LastCatch rule. The fact that DMD does what it does is a bug that has been documented for over a year.[1]

Implementing the spec, i.e. requiring exceptions to be named, would break far more code than what I propose.[3] If we want to have nameless exceptions, we need to change the specification to make the name optional. If we do that, the grammar becomes ambiguous. To fix the ambiguity we must either remove the LastCatch rule from the language spec[2] or introduce a rule for NoScopeNonEmptyStatement-that-doesn't-start-with-parens.


[1] https://issues.dlang.org/show_bug.cgi?id=10247
[2] https://issues.dlang.org/show_bug.cgi?id=12558
[3] I don't know how people uncover these undocumented features and build important code with them.

On 7/9/14, Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> There is no ambiguity in the grammar. "catch (A) { ... }" is not
> valid.

Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)'
be. We can change the spec if we have to, it's easier than breaking
code.

On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)'
> be. We can change the spec if we have to, it's easier than breaking code.

Huh? Brian explicitly remarked earlier that

> Implementing the spec, i.e. requiring exceptions to be named, would break far more code than what I propose,

and the DIP doesn't contain anything to that effect either

I'm a bit puzzled as to what the controversy is supposed to be about.

David

On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 7/9/14, Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> There is no ambiguity in the grammar. "catch (A) { ... }" is not
>> valid.
>
> Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)'
> be. We can change the spec if we have to, it's easier than breaking
> code.

I think Brian is being quite gracious with his proposal.  The offer to automate fixing users' code is especially generous.

Mike

On 7/9/14, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via Digitalmars-d wrote:
>> Give it a rest. If 'void foo(int, float)' is ok so should
>> 'catch (E)'
>> be. We can change the spec if we have to, it's easier than
>> breaking code.
>
> Huh? Brian explicitly remarked earlier that

Sorry, I misread what was being said.

On 7/9/2014 1:13 AM, Brian Schott wrote:
> There is no ambiguity in the grammar. "catch (A) { ... }" is not valid. The spec
> requires that you give the exception a name. A spec compliant D compiler MUST
> parse your example code with the LastCatch rule. The fact that DMD does what it
> does is a bug that has been documented for over a year.[1]

Sorry, I misunderstood. The relevant grammar is
https://dlang.org/statement#TryStatement :

 Catches:
    LastCatch
    Catch
    Catch Catches

 LastCatch:
    catch NoScopeNonEmptyStatement

 Catch:
    catch ( CatchParameter ) NoScopeNonEmptyStatement

 CatchParameter:
    BasicType Identifier

What the parser can do is do a lookahead on the ( ) to see if it matches the 'BasicType Identifier' grammar. Parser::isDeclaration() can be pressed into service to do that. This should resolve the issue without breaking code.

BTW, the reason for LastCatch is that it long predates the splitting of exceptions into the separate Error and Exception forks.

On Wednesday, 9 July 2014 at 20:11:46 UTC, Walter Bright wrote:
> What the parser can do is do a lookahead on the ( ) to see if it matches the 'BasicType Identifier' grammar. Parser::isDeclaration() can be pressed into service to do that. This should resolve the issue without breaking code.

There are 25 instances of code that does not follow the "BasicType Identifier" syntax for CatchParameter in Phobos alone.

std/exception.d:126:    catch (AssertError) assert(0);
std/exception.d:132:    catch (AssertError) assert(0);
std/exception.d:138:    catch (AssertError) assert(0);
std/exception.d:144:    catch (AssertError) assert(0);
std/exception.d:153:        catch (AssertError) thrown = true;
std/exception.d:164:        catch (AssertError) thrown = true;
std/exception.d:175:        catch (AssertError) thrown = true;
std/exception.d:187:        catch (AssertError) thrown = true;
std/exception.d:218:    catch (T)
std/exception.d:247:    catch (AssertError) assert(0);
std/exception.d:261:    catch (AssertError) assert(0);
std/exception.d:269:    catch (AssertError) assert(0);
std/socket.d:1406:        catch (SocketException)
std/conv.d:1509:        catch (E)
std/format.d:2359:        catch (UTFException)
std/stream.d:1382:    catch (Throwable)
std/stream.d:1419:    catch (Throwable)
std/array.d:2768:    catch (Exception) assert(0);
std/array.d:2781:    catch (Exception) assert(0);
std/array.d:2844:        catch (Exception) assert(0);
std/array.d:2858:        catch (Exception) assert(0);
std/array.d:3085:    catch (Exception) assert(0);
std/range.d:5107:        } catch (Throwable) { /* It's supposed to throw.*/ }
std/range.d:5402:    } catch (Exception) {}
std/range.d:9007:    catch (Throwable)

On 7/9/2014 1:58 PM, Brian Schott wrote:
> On Wednesday, 9 July 2014 at 20:11:46 UTC, Walter Bright wrote:
>> What the parser can do is do a lookahead on the ( ) to see if it matches the
>> 'BasicType Identifier' grammar. Parser::isDeclaration() can be pressed into
>> service to do that. This should resolve the issue without breaking code.
>
> There are 25 instances of code that does not follow the "BasicType Identifier"
> syntax for CatchParameter in Phobos alone.

Interesting. Those are invalid D code, but obviously the compiler is accepting it.

I suggest recognizing in the parser:

   ( Identifier )

as a special case, in addition to using Parser::isDeclaration(). Gradually we can turn that special case into a warning, then deprecation.