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.

On 09/28/2016 09:47 AM, Andrei Alexandrescu wrote:
> ...

I have added references to both your and Walter comments to DIP1002 review section: https://github.com/dlang/DIPs/pull/44

On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
> * 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".

Yeah... that's a pain.

How about using different keywords:

try
{
    // blah
}
/*else*/ catch (nothrow)
{
    // on success.
}

I submitted a PR addressing some of the mentioned criticisms: https://github.com/dlang/DIPs/pull/46

On Wednesday, 28 September 2016 at 11:17:05 UTC, pineapple wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * I saw in the forum that the "else" clause is supposed to run in the scope of the "try" statement, but that is not mentioned in the proposal. Even though that is the semantics in Python, that should be explicit in the document. The proposal should be standalone and fully specified without knowing Python or perusing external links.
>>
>> * The fact above (the "else" clause continues the scope of the statement after "try") is surprising, considering that the "catch" and "finally" clauses introduce their own scopes. The irregularity may confuse users. If the "else" clause is defined to introduce its own scope, it seems the advantages of the proposal are diminished.
>
> It was an idea that was raised, yes.
>
> If catch and finally don't continue the scope of try, then neither should else.
>
> That said, it might be preferable if they all did continue try's scope. But this would be a distinct and separate change.

I'm the one who suggested that, and I believe there is a very good reason why `else`'s scope behavior should differ from `catch`'s and `try`'s.

`catch` and `finally` should not continue `try`'s scope, because they can run even when `try` did not finish successfully(that's their purpose), which means the variables declared in `try` may or may not be initialized in the `catch` and `finally` blocks. For the same reason it's not useful to have them continue the scope - you can't use the variables declared in them if you don't know whether or not they have been initialized.

`else` is different - it is guaranteed to only execute if `try` finished successfully, which means all variables in the `try` block have had their initialization statements executed. Also, it's actually useful to have it continue the scope, because one may want to declare a variable in `try`(so they can `catch` exceptions in it's initialization) but use it in `else`(so the same exceptions in it's usage will bubble up).

This has little to do with Python's semantics. Python is an interpreted language so it doesn't bother with scope rules for control statements - either the initialization statement was executed and the variable is initialized, or it wasn't and the variable is not declared. D can not imitate this behavior...

On 9/28/16 7:58 AM, John Colvin wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * 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".
>
> Yeah... that's a pain.
>
> How about using different keywords:
>
> try
> {
>     // blah
> }
> /*else*/ catch (nothrow)
> {
>     // on success.
> }
>
>

No. Just no ;)

The more I think about this submission, I feel like the benefits are quite slim. The else clause is really simply a disabling of all the exception handlers at the end of the function. The uses seem very

There are some funky English problems too.

For example, should it be valid to use "else" without a catch? This reads weird:

try { ... }
else { ...}

I think probably the else should be invalid without a valid catch clause. Otherwise, you could just use scope(success).

The boolean to indicate an exception was thrown is cumbersome, but not horrible. Having the compiler manage the boolean may make this cleaner (e.g. finally(bool thrown)), I like it better than the else suggestion.

-Steve

On 9/28/16 1:56 PM, Steven Schveighoffer wrote:
>
> The more I think about this submission, I feel like the benefits are
> quite slim. The else clause is really simply a disabling of all the
> exception handlers at the end of the function. The uses seem very

Didn't finish this sentence. "very obscure"

-Steve

On 9/28/2016 12:47 AM, 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 motivation section should showcase examples that currently are not
> possible or are contorted in D, followed by their alternative implementation
> using the proposed feature. At best, the example would be taken from existing
> code (e.g. found in dub, phobos, etc). Next best is code that defines a
> plausible artifact.
>
> * The motivation section should also hypothesize on why the feature did not get
> traction in other languages than Python (Java, C++, C#). Also, it would be
> useful to show why D does need the feature even though it already has richer
> exception handing mechanisms by means of "scope".
>
> * 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.
>
> * [...] The proposal should be standalone and fully specified without knowing Python or
> perusing external links.
>
> * [...]  Please focus on
> examples that are meaningful and easy with the feature, difficult without.


These are great suggestions and apply generally. They should be added to the guide on doing a proper DIP.

On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer wrote:
> The more I think about this submission, I feel like the benefits are quite slim.

This is not and was not intended to be a glorious, incredible addition to the language. It is meant to shove D a couple inches further in the direction of modern programming constructs. Everywhere a programmer can use `else` instead of mucking about with a boolean success flag and having to make absolutely sure the code intended to handle a success state doesn't and will never be modified to throw an exception that the error handling code isn't designed for means less time spent on tedium, and less opportunity for programmer error.

On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer wrote:
> For example, should it be valid to use "else" without a catch?

Yes.

On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer wrote:
> The boolean to indicate an exception was thrown is cumbersome, but not horrible. Having the compiler manage the boolean may make this cleaner (e.g. finally(bool thrown)), I like it better than the else suggestion.

I think this would be an improvement over the current exception handling, but `else` is a pre-existing concept and making `finally` optionally accept a boolean this way tosses convention on its head, and not in a way I think is desireable. If what you're looking for is a clean solution, `finally(bool)` is definitely not it.

Moreover, Idan's suggestions about scope sharing make sense to me and I don't think his line of thinking would be compatible with doing it the way you suggest.

On Wednesday, 28 September 2016 at 20:18:06 UTC, pineapple wrote:
> This is not and was not intended to be a glorious, incredible addition to the language. It is meant to shove D a couple inches further in the direction of modern programming constructs. Everywhere a programmer can use `else` instead of mucking about with a boolean success flag and having to make absolutely sure the code intended to handle a success state doesn't and will never be modified to throw an exception that the error handling code isn't designed for means less time spent on tedium, and less opportunity for programmer error.

Or, more concisely:

Just because we have `for` doesn't mean we reject `foreach`.

Just because we have `while` doesn't mean we reject `for`.

Just because we have `goto` doesn't mean we reject `while`.