On 09/28/2016 04:21 PM, pineapple wrote:
> 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`.

A DIP should stay as far away from this kind of argument as possible. Redundancy of existing features should not be used as precedent and justification for adding another redundant feature.

The right angle here is to successfully present evidence that the frequency of a specific idiom/pattern is high enough to justify adding redundancy.

+cc Dicebot to add this to the guidelines


Thanks,

Andrei

On 9/29/2016 7:32 AM, Andrei Alexandrescu wrote:
> A DIP should stay as far away from this kind of argument as possible. Redundancy
> of existing features should not be used as precedent and justification for
> adding another redundant feature.

More generally, a problem with existing feature X is not a justification for introducing more instances of the problem.

This line of justification occurs regularly.

On 9/29/2016 4:45 AM, Marc Schütz wrote:
> And `Foo` could have `@disabled this()`, so you simply _can't_ declare it
> without initializing it

Foo foo = void;

On 29.09.2016 19:35, Walter Bright wrote:
> On 9/29/2016 7:32 AM, Andrei Alexandrescu wrote:
>> A DIP should stay as far away from this kind of argument as possible.
>> Redundancy
>> of existing features should not be used as precedent and justification
>> for
>> adding another redundant feature.
>
> More generally, a problem with existing feature X is not a justification
> for introducing more instances of the problem.
>
> This line of justification occurs regularly.
>

I posit you often just misunderstand what the argument is: It's more like: restriction A prevents B (B is what you think is bad), but it also prevents C and D (which are desirable), however, it does not even prevent E and F (which are arguably bad). Hence restriction A prevents many valid use cases without even effectively preventing "bad" usages.

On Tuesday, 27 September 2016 at 10:55:47 UTC, John Colvin wrote:
> but we don't (yet) have catch else, which is harder to immitate. Options are:
> A) the else clause is nothrow (in which case it can just go last inside the try)
> or
> B) store a flag and have to use immitation finally:
>
> {
>     /*finally*/ scope (exit) {}
>     bool exceptionThrown = false;
>     try {
>         doSomething();
>     } catch (Exception e) {
>         exceptionThrown = true;
>     }
>     /*else*/ if (!exceptionThrown) {}
> }

C) Use collectException:

import std.exception;
auto ex = collectException!MyException(doSomething());
if (ex) handleException(ex);
else {
    // doSomething succeeded
    ...
}

collectException could be improved to catch more than one type of exception, returning the common type. Alternatively it could maybe return a tuple of the exception and the 1-based index of which type of exception was thrown.

On Thursday, 29 September 2016 at 10:51:01 UTC, Nick Treleaven wrote:
> Assuming for a minute that we want some form of DIP1002, we might be able to extend the `try` scope in an interesting way:
>
> try {
>     auto f = foo();
> }
> catch (Exception) {
>     ...
> }
> finally (bool ok) { // true if no exception
>     bar();
>     __guard (ok) f.baz();
>     f.baz(); // error: f not in scope
> }
>

My 5 cents, let's play:

 try {
  ...
 }
 catch() { }
 catch() { }
 then { // I don't like idea to use 'else' very much. Please, don't use 'else' with try!
  ...
 }
 finally {
 }

let's be more generic

 try {
  ...
 }
 catch() { }
 catch() { }
 then {
  ...
 }
 catch() { }
 catch() { }
 then {
  ...
 }
 catch() { }
 catch() { }
 ...
 finally {
 }

(Hello from Javascript! But we have common scope here.)

or use guard in a more obvious place

 try {

  // in this code exceptions are routed to attached catch() blocks

  catch(MyException); // yes, this guard looks as stand-alone catch() to avoid new keywords, for example. May be bad idea, I don't know.

  // oops, in this code MyException ignores attached catch() blocks because of guard

 }
 catch() { }
 catch() { }
 finally {
 }

or make it again more generic

 try {

  // in this code exceptions are routed to attached catch() blocks as usual

  // ... but now catch() block can also be places inside of try block
  catch(MyException){
    // process
    // goto finally
  }

  // oops, this code below of catch(MyException), so...

 }
 catch() { }
 catch() { }
 finally {
 }

As for me, last variant is the most straightforward.

On Thursday, 29 September 2016 at 17:47:41 UTC, Walter Bright wrote:
> On 9/29/2016 4:45 AM, Marc Schütz wrote:
>> And `Foo` could have `@disabled this()`, so you simply _can't_ declare it
>> without initializing it
>
> Foo foo = void;

That's even worse. At least Foo.init would be deterministic.