DIP65: Fixing Exception Handling Syntax

[Walter Bright via Digitalmars-d]

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.