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


dfix file.d > file.d.fixed

meld file.d file.d.fixed

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