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.

Reply via email to