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

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

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.

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

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.

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.

Walter Bright:

> Unless a convincing counter argument emerges, yes.

Please Walter, list your convincing arguments to not fix the situation.

Bye,
bearophile

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.

Deprecation of LastCatch doesn't break existing code either.

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