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.

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

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.

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

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.

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.

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

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?

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

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;
		}
	}
}

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