www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP65: Fixing Exception Handling Syntax

reply "Brian Schott" <briancschott gmail.com> writes:
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.
Jul 08 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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(); }
Jul 08 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
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.
Jul 09 2014
next sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jul 09 2014
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Jul 09 2014
parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jul 09 2014
prev sibling parent "Mike" <none none.com> writes:
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
Jul 09 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 09 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
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)
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 09 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 9 July 2014 at 23:01:13 UTC, Walter Bright wrote:
 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.
If I'm understanding this correctly, you want to deprecate the (somewhat popular) nameless exception syntax so that we can keep the "should be removed with prejudice" catch-everything syntax? Other quotes about the syntax I propose removing: "...surprised it even compiled..." "Besides, how hard is it to just write: 'catch(Throwbale)'" "Perhaps we could add a compiler warning for catch without an explicit type."
Jul 09 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 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.
It's better to do the opposite, accept the common safe syntax "catch(Exception)" (it's common because often you don't need to give it a name, it's like function arguments without a variable name), and refuse the "catch all" that is dangerous, that is a bad practice even in Python. Bye, bearophile
Jul 10 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 07:50:47 UTC, bearophile wrote:
 Walter Bright:

 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.
It's better to do the opposite, accept the common safe syntax "catch(Exception)" (it's common because often you don't need to give it a name, it's like function arguments without a variable name), and refuse the "catch all" that is dangerous, that is a bad practice even in Python. Bye, bearophile
Agreed.
Jul 10 2014
prev sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
 If I'm understanding this correctly, you want to deprecate the 
 (somewhat popular) nameless exception syntax so that we can 
 keep the "should be removed with prejudice" catch-everything 
 syntax?
Is this the bottom line? Is DIP65 formally rejected? ping...
Jul 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/16/2014 4:04 PM, safety0ff wrote:
 On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
 If I'm understanding this correctly, you want to deprecate the (somewhat
 popular) nameless exception syntax so that we can keep the "should be removed
 with prejudice" catch-everything syntax?
Is this the bottom line? Is DIP65 formally rejected? ping...
Unless a convincing counter argument emerges, yes.
Jul 16 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 17 July 2014 at 04:41:14 UTC, Walter Bright wrote:
 On 7/16/2014 4:04 PM, safety0ff wrote:
 On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote:
 If I'm understanding this correctly, you want to deprecate 
 the (somewhat
 popular) nameless exception syntax so that we can keep the 
 "should be removed
 with prejudice" catch-everything syntax?
Is this the bottom line? Is DIP65 formally rejected? ping...
Unless a convincing counter argument emerges, yes.
I'll just go over the existing arguments because I think they're strong enough: 1. LastCatch is (in the opinion of many people) a misfeature. 2. LastCatch syntax is not used in Phobos. 3. LastCatch syntax is very, very trivial to update with a "dfix" tool. 4. The unnamed exception syntax is used 25 places in Phobos. 5. Making the spec consistent with itself[1] introduces a parse ambiguity. This makes tooling D more difficult. [1] "If just type T is given and no variable v, then the catch clause is still executed." Previously I was just reading the grammar spec and didn't catch this, but it turns out that this syntax IS present in the spec and has been for many years. Your plan of deprecating this syntax will break FAR more code than my plan for correctly documenting it.
Jul 16 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the situation. Bye, bearophile
Jul 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 1:28 AM, bearophile wrote:
 Walter Bright:

 Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the situation.
Breaks existing, working code for little gain. I suggested a fix that deals with the issue and does not break existing code.
Jul 17 2014
next sibling parent "Kagamin" <spam here.lot> writes:
Deprecation of LastCatch doesn't break existing code either.
Jul 17 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Breaks existing, working code for little gain. I suggested a 
 fix that deals with the issue and does not break existing code.
This is not yet convincing. Let's talk about the "Pokemon Exception Handling", for when you just Gotta Catch 'Em All :-) I think the D/Python code that uses this pattern is dangerous/smelly; so you are not breaking valid code, you are forbidding a coding pattern that in 99.5% cases good D code should not contain. Bye, bearophile
Jul 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 2:40 AM, bearophile wrote:
 Walter Bright:

 Breaks existing, working code for little gain. I suggested a fix that deals
 with the issue and does not break existing code.
This is not yet convincing. Let's talk about the "Pokemon Exception Handling", for when you just Gotta Catch 'Em All :-) I think the D/Python code that uses this pattern is dangerous/smelly; so you are not breaking valid code, you are forbidding a coding pattern that in 99.5% cases good D code should not contain.
At some point we need to stop breaking user code without really strong reasons. I don't see that any evidence that people who use such patterns have done so erroneously, just a supposition and a made up statistic. The onus is on a new feature and breaking change to prove its worth, the onus is not on those wishing to preserve the status quo. I.e. it's "why", not "why not" make a breaking change. Especially since it is apparently a commonly used coding pattern, appearing 25 times in Phobos alone.
Jul 17 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
 I.e. it's "why", not "why not" make a breaking change. 
 Especially since it is apparently a commonly used coding 
 pattern, appearing 25 times in Phobos alone.
What? The plan is to keep the syntax that is used in Phobos and get rid of the one that is not used. Part of the problem right now is that the grammar spec does not allow catch (ExceptionType) doStuff(); I want to change the grammar spec to include this syntax. I want to get rid of this: catch doStuff(); I thought that was clear.
Jul 17 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
 I.e. it's "why", not "why not" make a breaking change. 
 Especially since it is apparently a commonly used coding 
 pattern, appearing 25 times in Phobos alone.
It is used 0 times in Phobos. In fact I have not seen it used for a single time in any living project - guess because any sane person understands how terrible of a misfeature it is.
Jul 17 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:dikroykmroruujndliin forum.dlang.org...

 It is used 0 times in Phobos. In fact I have not seen it used for a single 
 time in any living project - guess because any sane person understands how 
 terrible of a misfeature it is.
I've used it, because I'm lazy. Usually something like: int x = 0; bool xisaninteger; try { x = to!int(args[2]); xisaninteger = true; } catch { } Sure, there are better ways to do it, but I don't care when I'm writing a quick script. You will break some code if you disallow it. Personally I don't mind, but it's not up to me.
Jul 17 2014
parent "Kagamin" <spam here.lot> writes:
On Thursday, 17 July 2014 at 10:38:46 UTC, Daniel Murphy wrote:
 You will break some code if you disallow it.
An alternative was presented here: a warning and deprecation.
Jul 17 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/8/14, 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 vote we reject this DIP. It has clear appeal but there's also the issue with putting currently correct code on a deprecation path, with no obvious win in quality. I think Walter's fix eliminates the problem during the semantic pass even though there's a grammar ambiguity. It's a judgment call, and by definition someone has to make it. Andrei
Jul 17 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 17 July 2014 at 19:28:31 UTC, Andrei Alexandrescu 
wrote:
 On 7/8/14, 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 vote we reject this DIP. It has clear appeal but there's also the issue with putting currently correct code on a deprecation path, with no obvious win in quality. I think Walter's fix eliminates the problem during the semantic pass even though there's a grammar ambiguity. It's a judgment call, and by definition someone has to make it. Andrei
Walter proposes putting currently correct code on a deprecation path with no obvious win in quality. He proposed getting rid of the "catch (SomeException)" syntax.
 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.
Jul 17 2014
prev sibling parent reply Justin Whear <justin economicmodeling.com> writes:
On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:

 On 7/8/14, 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 vote we reject this DIP. It has clear appeal but there's also the issue with putting currently correct code on a deprecation path, with no obvious win in quality. I think Walter's fix eliminates the problem during the semantic pass even though there's a grammar ambiguity. It's a judgment call, and by definition someone has to make it. Andrei
My understanding (and this is supported by hard numbers from Brian's survey of Phobos), is that Walter's proposal will perpetuate a bad design choice that is rarely if ever used (never in Phobos) in favor of deprecating a better syntax that is used (in Phobos and elsewhere). That is to say, we have hard numbers to prove that Walter's fix will deprecate currently working code while leaving us with the less-desirable syntax, while Brian's proposal will transition us to the more desirable syntax without breaking code written in the currently used idiom. And, as Brian pointed out[1], the current idiom of `catch (Throwable)` _is described_ in the spec, albeit not in the formal grammar. Ergo, Walter's fix also deprecates currently-working, correct syntax. Given that both are correct, but one is nearly completely unused and error prone, I vote yes on this DIP. [1] http://forum.dlang.org/thread/xmqzrgysgxdmqrnfpxdq forum.dlang.org? page=2#post-zsvbxhtbwevsrrflxzyr:40forum.dlang.org
Jul 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 1:44 PM, Justin Whear wrote:
 On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:

 On 7/8/14, 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 vote we reject this DIP. It has clear appeal but there's also the issue with putting currently correct code on a deprecation path, with no obvious win in quality. I think Walter's fix eliminates the problem during the semantic pass even though there's a grammar ambiguity. It's a judgment call, and by definition someone has to make it. Andrei
My understanding (and this is supported by hard numbers from Brian's survey of Phobos), is that Walter's proposal will perpetuate a bad design choice that is rarely if ever used (never in Phobos) in favor of deprecating a better syntax that is used (in Phobos and elsewhere). That is to say, we have hard numbers to prove that Walter's fix will deprecate currently working code while leaving us with the less-desirable syntax, while Brian's proposal will transition us to the more desirable syntax without breaking code written in the currently used idiom. And, as Brian pointed out[1], the current idiom of `catch (Throwable)` _is described_ in the spec, albeit not in the formal grammar. Ergo, Walter's fix also deprecates currently-working, correct syntax. Given that both are correct, but one is nearly completely unused and error prone, I vote yes on this DIP. [1] http://forum.dlang.org/thread/xmqzrgysgxdmqrnfpxdq forum.dlang.org? page=2#post-zsvbxhtbwevsrrflxzyr:40forum.dlang.org
Did you see my response? I suggested 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.
Jul 17 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 2:03 PM, Walter Bright wrote:
 Did you see my response?

 I suggested 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.
BTW, if doing the warning/deprecation on that is the sticking point, we don't have to do that. It doesn't change the issue with DIP65.
Jul 17 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
 Did you see my response?

 I suggested 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.
 turn that special case into .. deprecation
This is exactly the insane proposal referred to. ( Identifier ) , contrary to empty catch, is actually useful and widely used.
Jul 17 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:lq9dmc$2qeg$1 digitalmars.com...

 I suggested 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.
Why on earth would we deprecate that?
Jul 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 2:17 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:lq9dmc$2qeg$1 digitalmars.com...

 I suggested 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.
Why on earth would we deprecate that?
I had thought everyone hated that. Seems that either I heard wrong or people changed their mind :-) In any case, I have no issue with not deprecating it.
Jul 17 2014
prev sibling next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
On Thu, 17 Jul 2014 14:03:06 -0700, Walter Bright wrote:

 On 7/17/2014 1:44 PM, Justin Whear wrote:
 On Thu, 17 Jul 2014 12:28:33 -0700, Andrei Alexandrescu wrote:

 On 7/8/14, 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 vote we reject this DIP. It has clear appeal but there's also the issue with putting currently correct code on a deprecation path, with no obvious win in quality. I think Walter's fix eliminates the problem during the semantic pass even though there's a grammar ambiguity. It's a judgment call, and by definition someone has to make it. Andrei
My understanding (and this is supported by hard numbers from Brian's survey of Phobos), is that Walter's proposal will perpetuate a bad design choice that is rarely if ever used (never in Phobos) in favor of deprecating a better syntax that is used (in Phobos and elsewhere). That is to say, we have hard numbers to prove that Walter's fix will deprecate currently working code while leaving us with the less-desirable syntax, while Brian's proposal will transition us to the more desirable syntax without breaking code written in the currently used idiom. And, as Brian pointed out[1], the current idiom of `catch (Throwable)` _is described_ in the spec, albeit not in the formal grammar. Ergo, Walter's fix also deprecates currently-working, correct syntax. Given that both are correct, but one is nearly completely unused and error prone, I vote yes on this DIP. [1] http://forum.dlang.org/thread/xmqzrgysgxdmqrnfpxdq forum.dlang.org? page=2#post-zsvbxhtbwevsrrflxzyr:40forum.dlang.org
Did you see my response? I suggested 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.
Yes, this confuses me. You are suggesting that we add special casing to the compiler to recognize syntax that _currently works_ so that we can then gradually deprecate it. More confusing to me is why you are choosing to deprecate the correct, often-used syntax and retain the correct, rarely-used syntax. I'm trying to see the motivation for your proposal when it will likely break more code (if the warning, deprecation path is followed) than Brian's and result in a less-desirable catch-all syntax. The reason I decided to weigh in on this thread in the first place is it seemed that you and Brian were talking past each other, and I'm wondering if that is still happening. So to lay it out, my understanding is that DIP65 proposes: 1) Fixing the grammar to accurately the _current_ state of the parser and spec, i.e. `catch (Throwable)`. This syntax is used in Phobos. Brian should update the DIP under "Rationale" such that bullet 1 goes from: "Exceptions are not required to have names by the compiler (The language specification requires names)" to read "Exceptions are not required to have names by the compiler or spec, but the grammar does require it." 2) Warning, then deprecating the LastCatch syntax. This syntax is not used in Phobos. All LastCatches can be simply and mechanically replaced with `catch (Throwable)`. Now obviously Phobos is not necessarily representative of all user code, but I think that going from less-specific to more specific (e.g. do you want to catch all Exceptions? Or all Throwables?) is better for the language. Given that it's a completely mechanical change, if something is going to be deprecated it should be the less used, less preferable syntax.
Jul 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 2:29 PM, Justin Whear wrote:
 I suggested 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.
Yes, this confuses me. You are suggesting that we add special casing to the compiler to recognize syntax that _currently works_ so that we can then gradually deprecate it. More confusing to me is why you are choosing to deprecate the correct, often-used syntax and retain the correct, rarely-used syntax. I'm trying to see the motivation for your proposal when it will likely break more code (if the warning, deprecation path is followed) than Brian's and result in a less-desirable catch-all syntax.
As I posted elsewhere, in the past there were many complaints about the ( Exception ) syntax and an expressed desire to deprecate it. I was going along with that. But apparently those people who wanted it deprecated are either silent in this thread or have changed their mind. It's no matter, I withdraw my suggestion to deprecate it.
 2) Warning, then deprecating the LastCatch syntax.
This I object to, on the basis of breaking existing code.
 This syntax is not
 used in Phobos.  All LastCatches can be simply and mechanically replaced
 with `catch (Throwable)`.
Writing such a tool is a major operation.
 Now obviously Phobos is not necessarily representative of all user code,
 but I think that going from less-specific to more specific (e.g. do you
 want to catch all Exceptions? Or all Throwables?) is better for the
 language.  Given that it's a completely mechanical change, if something
 is going to be deprecated it should be the less used, less preferable
 syntax.
We need to STOP breaking existing code. I just got another report from a user sighing over changes from 2.064 to 2.065 breaking his projects. Even simple changes are very annoying when people have existing, working code bases. I get irritated when my own code breaks from changes I proposed. We need to have very strong reasons going forward for breaking existing code. In my opinion, this is not near that bar.
Jul 17 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical existing code: https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265 The fear of breaking code should NOT freeze our brains in terror. For each sigh of broken code could exist one thousand sighs caused by broken designs that will keep causing troubles forever. Bye, bearophile
Jul 17 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
 Walter Bright:

 We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical existing code: https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265 The fear of breaking code should NOT freeze our brains in terror. For each sigh of broken code could exist one thousand sighs caused by broken designs that will keep causing troubles forever.
Your proposal there is much much worse than one to deprecate `catch()` - it may result in silent change of behavior while this DIP results in reliable transition process via compile-time error. In my opinion this is exactly the borderline between "can't break at all" and "can do if change is reasonable" - having 100% reliable and simple migration process. If only we had more casual major releases..
Jul 17 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 Your proposal there is much much worse than one to deprecate 
 `catch()` - it may result in silent change of behavior
Yes, sorry. Bye, bearophile
Jul 17 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 3:01 PM, Dicebot wrote:
 On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
 Walter Bright:

 We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical existing code: https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265 The fear of breaking code should NOT freeze our brains in terror. For each sigh of broken code could exist one thousand sighs caused by broken designs that will keep causing troubles forever.
Your proposal there is much much worse than one to deprecate `catch()` - it may result in silent change of behavior
That would be serious. What code would change behavior with Walter's proposal? -- Andrei
Jul 17 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 18 July 2014 at 00:48:38 UTC, Andrei Alexandrescu 
wrote:
 That would be serious. What code would change behavior with 
 Walter's proposal? -- Andrei
That was an answer to bearophile, not Walter, false alarm ;)
Jul 17 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 2:51 PM, bearophile wrote:
 Walter Bright:

 We need to STOP breaking existing code.
This is a small example case where I suggest to break hypothetical existing code: https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265 The fear of breaking code should NOT freeze our brains in terror. For each sigh of broken code could exist one thousand sighs caused by broken designs that will keep causing troubles forever.
Doesn't seem like terror to me. Thing is there's got to be a win there for the breakage to be justified. -- Andrei
Jul 17 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
 Walter Bright:

 The fear of breaking code should NOT freeze our brains in 
 terror. For each sigh of broken code could exist one thousand 
 sighs caused by broken designs that will keep causing troubles 
 forever.
+1 --- Paolo
Jul 20 2014
prev sibling next sibling parent Justin Whear <justin economicmodeling.com> writes:
On Thu, 17 Jul 2014 14:43:59 -0700, Walter Bright wrote:

 As I posted elsewhere, in the past there were many complaints about the
 ( Exception ) syntax and an expressed desire to deprecate it. I was
 going along with that. But apparently those people who wanted it
 deprecated are either silent in this thread or have changed their mind.
 
 It's no matter, I withdraw my suggestion to deprecate it.
Thanks, this clarifies a lot. Given that this syntax both explicitly allowed by spec documentation and used in Phobos, we should consider adding it to the grammar, which is covered by the second part of DIP65:
 The CatchParameter rule is rewritten as follows:
 CatchParameter:
     BasicType Identifier?
Jul 17 2014
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
 Writing such a tool is a major operation.
// I disagree. module dfix; import std.lexer; import std.d.lexer; import std.array; import std.stdio; void main(string[] args) { File input = File(args[1]); File output = args.length > 2 ? File(args[2]) : stdout; ubyte[] inputBytes = uninitializedArray!(ubyte[])(input.size); input.rawRead(inputBytes); StringCache cache = StringCache(StringCache.defaultBucketCount); LexerConfig config; config.fileName = args[1]; config.stringBehavior = StringBehavior.source; auto tokens = byToken(inputBytes, config, &cache).array; foreach (i; 0 .. tokens.length) { switch (tokens[i].type) { case tok!"catch": if (i + 1 < tokens.length && tokens[i + 1].type != tok!"(") { output.write("catch (Throwable)"); break; } else goto default; default: output.write(tokens[i].text is null ? str(tokens[i].type) : tokens[i].text); break; } } }
Jul 17 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
 On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
 Writing such a tool is a major operation.
// I disagree.
Posted a bit too soon. Should look more like this.. case tok!"catch": size_t j = i + 1; while (j < tokens.length && (tokens[j] == tok!"whitespace" || tokens[j] == tok!"comment")) j++; if (j < tokens.length && tokens[j].type != tok!"(") { The lexer code is here: https://github.com/Hackerpilot/libdparse
Jul 17 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 3:13 PM, Brian Schott wrote:
 On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
 On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
 Writing such a tool is a major operation.
// I disagree.
Posted a bit too soon. Should look more like this.. case tok!"catch": size_t j = i + 1; while (j < tokens.length && (tokens[j] == tok!"whitespace" || tokens[j] == tok!"comment")) j++; if (j < tokens.length && tokens[j].type != tok!"(") { The lexer code is here: https://github.com/Hackerpilot/libdparse
Whatever comes of DIP65, it shouldn't influence our determination to define such a tool. -- Andrei
Jul 17 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 18 July 2014 at 00:50:33 UTC, Andrei Alexandrescu 
wrote:
 Whatever comes of DIP65, it shouldn't influence our 
 determination to define such a tool. -- Andrei
I started with proposing this syntax change because it is the easiest thing I can think of to fix automatically. Dfix should start small and it doesn't get smaller than this.
Jul 17 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 5:57 PM, Brian Schott wrote:
 On Friday, 18 July 2014 at 00:50:33 UTC, Andrei Alexandrescu wrote:
 Whatever comes of DIP65, it shouldn't influence our determination to
 define such a tool. -- Andrei
I started with proposing this syntax change because it is the easiest thing I can think of to fix automatically. Dfix should start small and it doesn't get smaller than this.
I agree. I also internally decided I have a personal mild preference in favor of DIP65, i.e. I'm agreeing with you and disagreeing with Walter. But I'll let it go because: 1. There is clear understanding of the DIP65 on Walter (and my) part. 2. Reasonable people may disagree on the best course of action. 3. Somebody must make a judgment call. 4. It's neither a huge win nor a disaster any way the call goes. 5. In Walter's words - if he and I agreed on everything, we wouldn't be doing our jobs. Same about other community members etc. 6. Part of moving forward is breaking clean with the past. I think there's better fruit to pluck here. Regarding dfix, I have a suggestion for a simple start - how about rewriting alias B A; as alias A = B; I've been reading a bunch of Thrift code using the old syntax and the new one is quite easier on the eyes when B is complex. Andrei
Jul 17 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 3:07 PM, Brian Schott wrote:
 On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
 Writing such a tool is a major operation.
// I disagree. [...]
I'm impressed. I withdraw that comment.
Jul 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 3:17 PM, Walter Bright wrote:
 On 7/17/2014 3:07 PM, Brian Schott wrote:
 On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
 Writing such a tool is a major operation.
// I disagree.
> [...] I'm impressed. I withdraw that comment.
BTW, it's not perfect because of token string literals and string mixins, but it's good enough.
Jul 17 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 BTW, it's not perfect because of token string literals and 
 string mixins, but it's good enough.
In general the creation of a tool like Go fix (http://golang.org/cmd/fix/ ) for D could change a little the trade-offs regarding the tiny Phobos/D breaking changes. Bye, bearophile
Jul 17 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 11:39:56PM +0000, bearophile via Digitalmars-d wrote:
 Walter Bright:
 
BTW, it's not perfect because of token string literals and string
mixins, but it's good enough.
In general the creation of a tool like Go fix (http://golang.org/cmd/fix/ ) for D could change a little the trade-offs regarding the tiny Phobos/D breaking changes.
[...] This got me thinking, if dmd came with a -fix option, perhaps, that will either automatically fix your code or print out a list of suggested fixes, then perhaps breaking changes might be more palatable? For example: 1) I install dmd 2.065, and write my project according to it. 2) I see that 2.066 has been released, so I download and install it. 3) When I try to compile my project, it tells me: yourcode.d(123): deprecated syntax, please run with -fix to automatically correct it, or -d to compile according to 2.065 syntax. 4) I don't have time to verify the fixes at this time, so I run dmd with -d to get my product out the door. 5) 2 weeks later, I have some free time, so I run dmd -fix on my code to upgrade to the new syntax. Then I review the changes and approve them. Or, alternatively, I run dmd -fix -diffonly to see what the compiler's suggestions of changes are, and modify my code by hand accordingly. 6) Now I can compile with "native" 2.066 mode. Once this pattern becomes established, it can be simplified into just: 1) Install 2.065. Compile my project. 2) Upgrade to 2.066. 3) Run dmd -fix (upgrade syntax after each compiler upgrade). 4) Compile my project as before. 5) ... ditto T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Jul 17 2014
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
 Did you see my response?

 I suggested recognizing in the parser:

    ( Identifier )

 as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this special case is lacking, and will inevitably cause someone a headache when they try to do something like: catch(typeof(foo)) { ... } Which is currently valid (as I'd expect).
Jul 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/21/2014 3:41 AM, Jakob Ovrum wrote:
 On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
 Did you see my response?

 I suggested recognizing in the parser:

    ( Identifier )

 as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this special case is lacking, and will inevitably cause someone a headache when they try to do something like: catch(typeof(foo)) { ... } Which is currently valid (as I'd expect).
That can be special cased, too.
Jul 25 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
 That can be special cased, too.
Seriously? Where does it end? catch(MyTemplatedException!true) { } Parsing this as a proper type without a trailing identifier is a nice feature that a lot of people use, unlike the ghastly catch {} feature that nobody uses and should be considered harmful. Whether we constrain the former or kill the latter, they're both breaking changes. So why are we favouring the *bad* one?
Jul 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
 On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
 That can be special cased, too.
Seriously? Where does it end? catch(MyTemplatedException!true) { }
That one can't be special cased in the parser.
 Parsing this as a proper type without a trailing identifier is a nice feature
 that a lot of people use, unlike the ghastly catch {} feature that nobody uses
 and should be considered harmful. Whether we constrain the former or kill the
 latter, they're both breaking changes. So why are we favouring the *bad* one?
Because it breaks the least amount of code.
Jul 25 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Because it breaks the least amount of code.
This is not a good idea. What about the future code that will be buggy/wrong? Bye, bearophile
Jul 25 2014
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 25 July 2014 at 21:34:22 UTC, Walter Bright wrote:
 On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
 On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
 That can be special cased, too.
Seriously? Where does it end? catch(MyTemplatedException!true) { }
That one can't be special cased in the parser.
 Parsing this as a proper type without a trailing identifier is 
 a nice feature
 that a lot of people use, unlike the ghastly catch {} feature 
 that nobody uses
 and should be considered harmful. Whether we constrain the 
 former or kill the
 latter, they're both breaking changes. So why are we favouring 
 the *bad* one?
Because it breaks the least amount of code.
I hope you are running head first into a usability disaster here. From a user's perspective, MyTemplatedException!true is a type just like MyException is and there is no reason why it should work differently. Remember built-in types and alias parameters? Let's just get rid of "catch {}" which encourages unsafe code and be done with it. David
Jul 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code and be done with
it.
We need to stop breaking code.
Jul 25 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 We need to stop breaking code.
We also have a responsibility for the bad D code yet to be written :-) Bye, bearophile
Jul 25 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
 On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code 
 and be done with it.
We need to stop breaking code.
Either change breaks code. There's no evidence to support that catch{} is more commonly used than catch(MyException!true) et al.
Jul 25 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 26 July 2014 at 00:10:00 UTC, Jakob Ovrum wrote:
 On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
 On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code 
 and be done with it.
We need to stop breaking code.
Either change breaks code. There's no evidence to support that catch{} is more commonly used than catch(MyException!true) et al.
If you download D-Scanner and run "dscanner --styleCheck -R path/to/code" you can easily tell if the LastCatch syntax is being used. The message you get is "Catching Error or Throwable is almost always a bad idea." If you find out that some code IS using this old syntax, this tool will fix it automatically: https://gist.github.com/Hackerpilot/5ff6d86f4d22a14a00f3 # Run upgrade dfix file.d > file.d.fixed # Check that it worked as expected meld file.d file.d.fixed # Overwrite old file mv file.d.fixed file.d
Jul 25 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
 On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code 
 and be done with it.
We need to stop breaking code.
IMO breaking changes are justified if the changes fix a design flaw in the language or the changes break code that should have never been permitted. Mike
Jul 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2014 6:13 PM, Mike wrote:
 IMO breaking changes are justified if the changes fix a design flaw in the
 language or the changes break code that should have never been permitted.
Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.
Jul 25 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
 On 7/25/2014 6:13 PM, Mike wrote:
 IMO breaking changes are justified if the changes fix a design 
 flaw in the
 language or the changes break code that should have never been 
 permitted.
Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.
The fact that you consider this "ironical" means that you have completely missed my point yet again and don't really see the "catch 22" problem with current attitude. (mentioned argument is here : https://github.com/D-Programming-Language/phobos/pull/2366#issuecomment-50215483) tl; dr: - breaking changes are good - lack of any formal process for breaking changes is bad - pretending that careful decisions for breakage make big difference is not understanding the problem
Jul 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2014 6:40 PM, Dicebot wrote:
 tl; dr:
 - breaking changes are good
 - lack of any formal process for breaking changes is bad
 - pretending that careful decisions for breakage make big difference is not
 understanding the problem
I believe we are talking past each other with no understanding.
Jul 25 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I believe we are talking past each other with no understanding.
The roadmap for the next three versions of Scala. Despite Scala is used much more than D, they are willing to break library code (shuffle around collections, turn mutable ones into immutable ones), and change first of all the type system, to consolidate and simplify it (beside making the compiler faster, removing bugs, introducing value types, etc): http://scala-lang.org/news/roadmap-next I am not a Scala expert, but those look like significant changes. Bye, bearophile
Jul 29 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
 On 7/25/2014 6:13 PM, Mike wrote:
 IMO breaking changes are justified if the changes fix a design 
 flaw in the
 language or the changes break code that should have never been 
 permitted.
Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.
Isn't that to be expected in your position? There will be consequences if a decision is made to not break code, and there will be consequences if a decision is made to break code. Principles like the 2 I mentioned would help, but Brian's work (std.d.lexer, DScanner, etc...) is showing immense value here in creating a "go tool fix"-like utility [1]. If we (that includes me) would support it and make it a priority, we wouldn't have to take such a hard-line stance on breaking changes. Mike [1] http://golang.org/cmd/fix/
Jul 25 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
 Ironically, today I'm being vehemently argued with for both 
 breaking code and not breaking code.
Are the arguments about intentional or unintentional breakages?
Jul 26 2014
prev sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
 On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code 
 and be done with it.
We need to stop breaking code.
At SR Labs, we have no problems at all with that kind of breakage: the LOCS of D code here is growing big, so let's take that kind of adjustment to the language right now, thinking a lot about it, but right now and for a better language. That kind of braking are in the opinion of my company really a no-issue. --- Paolo
Jul 26 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 26 July 2014 at 10:48:56 UTC, Paolo Invernizzi wrote:
 On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
 On 7/25/2014 3:56 PM, David Nadlinger wrote:
 Let's just get rid of "catch {}" which encourages unsafe code 
 and be done with it.
We need to stop breaking code.
At SR Labs, we have no problems at all with that kind of breakage: the LOCS of D code here is growing big, so let's take that kind of adjustment to the language right now, thinking a lot about it, but right now and for a better language. That kind of braking are in the opinion of my company really a no-issue.
+1 The compiler will detect it, it can suggest what to use instead, and it can even be properly deprecated first. "Bad" breakage are things that break silently. This, however, is an example of "good" breakage, as it can be detected easily, there is a clear migration path, and it is an overall improvement to the language.
Jul 26 2014
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/25/2014 11:34 PM, Walter Bright wrote:
 On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
 On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
 That can be special cased, too.
Seriously? Where does it end? catch(MyTemplatedException!true) { }
That one can't be special cased in the parser.
I'd suggest to just special case the general thing, or not add any special cases at all. catch(Type) ^~~~~~ I.e. use lookahead to determine whether something that looks like a type follows a '(' token and is itself followed by a ')' token.
Jul 28 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
 I'd suggest to just special case the general thing, or not add 
 any special cases at all.

 catch(Type)
      ^~~~~~

 I.e. use lookahead to determine whether something that looks 
 like a type follows a '(' token and is itself followed by a ')' 
 token.
This doesn't help. catch (Type).functionName() is valid both as LastCatch PostfixExpression PostfixExpression PostfixExpression PrimaryExpression '(' Type ')' '.' identifier '(' ')' And as Catch '(' Type ')' PrimaryExpression '.' PostfixExpression PrimaryExpression 'functionName' '(' ')'
Jul 28 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2014 09:32 PM, Brian Schott wrote:
 On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
 I'd suggest to just special case the general thing, or not add any
 special cases at all.

 catch(Type)
      ^~~~~~

 I.e. use lookahead to determine whether something that looks like a
 type follows a '(' token and is itself followed by a ')' token.
This doesn't help. ...
Depends on what outcome one is after.
 catch (Type).functionName() is valid both as

 LastCatch
   PostfixExpression
    PostfixExpression
     PostfixExpression
      PrimaryExpression
       '(' Type ')'
     '.' identifier
    '(' ')'

 And as

 Catch
   '(' Type ')'
   PrimaryExpression
    '.'
    PostfixExpression
     PrimaryExpression
      'functionName'
     '(' ')'
Obviously, hence the alternative suggestion to not add any special cases (and then the most sensible way out seems to be to just retire the catch-all syntax). (But as you're likely to know, there are some of those cases already (if less severe): foreach(i;0..n){ // ... } (&x).foo(); The above is grammatically ambiguous, but DMD parses it as two distinct statements using an ad-hoc disambiguation rule. try{ // ... }catch(Exception e){ return e; } (new Exception("hi")).msg.writeln; Similarly. In contrast to above, the alternative parsing might actually pass the type checker.)
Jul 28 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
 foreach(i;0..n){
     // ...
 }
 (&x).foo();

 try{
    // ...
 }catch(Exception e){
     return e;
 }
 (new Exception("hi")).msg.writeln;
I don't see how these are ambiguous.
Jul 28 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2014 10:23 PM, Brian Schott wrote:
 On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
 foreach(i;0..n){
     // ...
 }
 (&x).foo();

 try{
    // ...
 }catch(Exception e){
     return e;
 }
 (new Exception("hi")).msg.writeln;
I don't see how these are ambiguous.
Both are ambiguous for the same reason. They are ambiguous because there exist delegate/function literals of the form enum e={ return 2; }(); ^~~~~~~~~~~~~ an expression The following program demonstrates how to disambiguate the code such that it is parsed in the alternative way: import std.stdio; void bar(){ foreach(x;0..10)(){ // ... } (&x).foo(); } void main(){ Exception e(){ try{ // ... throw new Exception("foo"); }catch delegate(Exception e){ return e; }(new Exception("hi")).msg.writeln; return null; } e(); }
Jul 28 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Monday, 28 July 2014 at 20:51:55 UTC, Timon Gehr wrote:
 Both are ambiguous for the same reason. They are ambiguous 
 because there exist delegate/function literals of the form

 enum e={ return 2; }();
        ^~~~~~~~~~~~~
        an expression
ForeachStatement: ... NoScopeNonEmptyStatement ... PrimaryExpression: FunctionLiteral FunctionLiteral: FunctionBody FunctionBody: BlockStatement I had forgotten about this particular WTF.
Jul 28 2014