Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 08, 2014 DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
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. |
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | 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(); }
|
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | 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.
|
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 |
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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
|
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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.
|
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | 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. |
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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)
|
July 09, 2014 Re: DIP65: Fixing Exception Handling Syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | 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.
|
Copyright © 1999-2021 by the D Language Foundation