DIP 1002 (TryElseExpression) added to the queue

[Dicebot via Digitalmars-d]

On 09/28/2016 01:17 PM, pineapple wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * Please remove colloquialisms. Characterizations such as
>> "fantastically useful" are unlikely to be a convincing motivator and
>> have no place in a DIP.
>>
>> * The "Description" section should be more detailed and less casual.
>> The grammar changes should be shown in a syntax similar to the current
>> grammar definition.
> 
> These were not documented as a requirement anywhere that I saw. I'd have
> been happy to comply, if I had known this was the practice.

As the new DIP process is very young, set of requirements is being
fleshed out as we go. Basically what happens is that DIP gets into the
queue, Andrei and Walter point out what they don't like and I take
notice of it to add to the documented requirements.

Merged draft DIPs are not set in stone - Andrei's comment is not sign of
immediate rejection but a request to make a PR to improve mentioned things.

>> * The "Breaking changes" section should include how the following
>> change in semantics would be addressed. Consider:
>>
>>   try
>>     if (expression)
>>         try { ... }
>>         catch (Exception) { ... }
>>     else { ... }
>>   finally { ... }
>>
>> This code is currently legal and binds the "else" clause to the "if"
>> and the "finally" to the first "try". The proposed feature will bind
>> the "else" and the "finally" to the second try and then probably fail
>> to compile because there is no "catch" or "finally" matching the first
>> "try".
> 
> This possibility hadn't occurred to me. Is that really legal?

Yes. `try` body is a single statement or block and `if/else` is a legal
single statement. Same for `if` statement and `try/catch`.

> If so, I'd argue ... that
> people shouldn't write such ambiguous code.

Proposing language change is a serious responsibility and speculations
about how developers should or should not write their code have no place
there.

If something is currently legal, breaking changes sections _must_
provide means to mitigate the damage or proposal should not be accepted
no matter how good it is.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160928/3dab46bd/attachment.sig>