Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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'
'(' ')'
Re: DIP65: Fixing Exception Handling Syntax
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.)
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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();
}
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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?
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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?
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
Walter Bright: We need to stop breaking code. We also have a responsibility for the bad D code yet to be written :-) Bye, bearophile
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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/
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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).
Re: DIP65: Fixing Exception Handling Syntax
Walter Bright: Unless a convincing counter argument emerges, yes. Please Walter, list your convincing arguments to not fix the situation. Bye, bearophile
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
Deprecation of LastCatch doesn't break existing code either.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
Dicebot wrote in message news:dikroykmroruujndl...@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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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/xmqzrgysgxdmqrnfp...@forum.dlang.org? page=2#post-zsvbxhtbwevsrrflxzyr:40forum.dlang.org
Re: DIP65: Fixing Exception Handling Syntax
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/xmqzrgysgxdmqrnfp...@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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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?
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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/xmqzrgysgxdmqrnfp...@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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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?
Re: DIP65: Fixing Exception Handling Syntax
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..
Re: DIP65: Fixing Exception Handling Syntax
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;
}
}
}
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
On Thu, Jul 17, 2014 at 11:39:56PM +, 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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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 ;)
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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...
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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)
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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.
Re: DIP65: Fixing Exception Handling Syntax
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(); }
