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.

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.

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.

"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. 

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.

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

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.

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

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.

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.