On Friday, 4 November 2016 at 19:26:23 UTC, Steven Schveighoffer wrote:
>> I think it makes it easier to read and it fits with how the
>> for-statement operates. I write code everyday that could utilize this
>> if-statement syntax, so I thought I might as well bring it up. But if
>> there isn't that much interest in it then I won't bother with a DIP.
>
> Please bear in mind that I'm not the gatekeeper, so what I say may not be what the actual ones in control think. It's possible that Walter and Andrei like the idea and would implement if someone fleshed out the proposal. In my experience, I have not encountered too many cases (definitely not zero though) where I needed such a feature. I can see the utility, and I wouldn't be opposed to it.
>
> -Steve

No but you do make a compelling case. Having the scope structured the way you did removed the extra indention and it isn't as error prone as the other methods. You could also have multiple declarations which I don't think work (at least in the C++ implementation) for the new if-statement.

{int a; double b; if(func(&a, &b) >= 0)
{
}}

On Thursday, November 03, 2016 22:29:34 Jerry via Digitalmars-d wrote:
>      if(int i = someFunc(); i >= 0)
>      {
>          // use i
>      }
> Thoughts on this sort of feature?

Personally, I'd love to have it, and I think that it's been suggested before (though I don't remember how that discussion went). I think that it would be a nice syntactic improvement over what Stefan suggested with an additional set of braces. It also would work with the else if case, whereas adding an extra scope would not. And I think that any chance of it actually being added to the language would hinge on its ability to either make stuff possible which is not currently possible or on its ability to make stuff that's really awkward easy to do in a non-awkward way. And there's a better case to be made that

if(cond)
{
}
else if(auto result = foo(); cond2)
{
}
else if(cond3)
{
}

is harder to emulate with the current language than doing it with the first if - though even with the first if branch, if you have something like

if(auto result = foo(); cond1)
{
}
else if(cond2)
{
}
else if(cond3)
{
}

the variable created in the first if branch would presumably leave scope immediately after the condition failed, which would also be much more difficult to emulate by adding additional braces.

So, maybe it could be argued successfully with a DIP, but in general at this point, I think that Walter and Andrei are very resistant to making changes to the language - especially when it's simply for aesthetic benefit. So, any proposing a feature needs to be able to show that it brings real value. And while I, personally, think that this brings real value for certain use cases, I don't know if it brings enough value in general to be worth the addition, and more importantly, I don't know if Walter or Andrei would think that it's worth it, and they're the ones who need to be convinced.

Ultimately though, the biggest hurdle is that someone needs to create a DIP for it that strongly argues its case with real world examples of how it would improve code (preferably with code from Phobos and code.dlang.org), and without a really well-written DIP it's going to be dead in the water unless Walter or Andrei already happened to have wished for something like that often enough that they didn't take much convincing (which I wouldn't bet on). Right now, the bar to get a new feature in is pretty high even simply from the standpoint of the amount of work required to successfully propose it.

- Jonathan M Davis

On Saturday, 5 November 2016 at 19:52:05 UTC, Jonathan M Davis wrote:
> and more importantly, I don't know if Walter or Andrei would think that it's worth it, and they're the ones who need to be convinced.

this addition looks like needless overcomplication even for me. and i'm usually collecting feature for aliced without any formalities. ;-)

On 11/5/16 3:52 PM, Jonathan M Davis via Digitalmars-d wrote:
> Ultimately though, the biggest hurdle is that someone needs to create a DIP
> for it that strongly argues its case with real world examples of how it
> would improve code (preferably with code from Phobos and code.dlang.org),
> and without a really well-written DIP it's going to be dead in the water

The declaration with "if" seems to be a recent fashion. I've first seen it in Go and now C++17 took a shine to it - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html. A DIP would do good to cite that related work.

It seems a low impact feature. Also, the Go/C++ syntaxes seem suboptimal to me because they are stuttering:

if variable := fun(); variable != 42 {
  ...
}

or (C++):

if (auto variable = fun(); variable != 42) {
  ...
}

Why does the word "variable" need to appear twice? It seems simpler to allow punctuation around existing syntax:

// possible future D
if ((auto variable = fun()) != 42) {
  ...
}

Defining a variable in an expression wouldn't be allowed everywhere (but might be contemplated later as an possibility, which is a nice thing about this syntax).

A more approachable thing to do is allow variable definitions in switch statements:

switch (auto x = fun() { ... }

It is surprising that doesn't work, which is a good argument in favor of the feature (removal of an undue limitation, rule of least astonishment etc).


Andrei

On Sunday, 6 November 2016 at 05:07:10 UTC, Andrei Alexandrescu wrote:
> A more approachable thing to do is allow variable definitions in switch statements:
>
> switch (auto x = fun() { ... }
>
> It is surprising that doesn't work, which is a good argument in favor of the feature (removal of an undue limitation, rule of least astonishment etc).

https://issues.dlang.org/show_bug.cgi?id=11070
lol

On Sunday, 6 November 2016 at 05:07:10 UTC, Andrei Alexandrescu wrote:
>
> The declaration with "if" seems to be a recent fashion. I've first seen it in Go and now C++17 took a shine to it - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html. A DIP would do good to cite that related work.
>
> It seems a low impact feature. Also, the Go/C++ syntaxes seem suboptimal to me because they are stuttering:
>
> if variable := fun(); variable != 42 {
>   ...
> }
>
> or (C++):
>
> if (auto variable = fun(); variable != 42) {
>   ...
> }
>
> Why does the word "variable" need to appear twice? It seems simpler to allow punctuation around existing syntax:
>
> // possible future D
> if ((auto variable = fun()) != 42) {
>   ...
> }
>
> Defining a variable in an expression wouldn't be allowed everywhere (but might be contemplated later as an possibility, which is a nice thing about this syntax).
>
> Andrei

I remember an old suggestion/DIP allowing 'with' statements to introduce/declare symbols/variables.

Might be a cleaner extension to existing language:

with(auto x = f()) if(foo(x)) {}
else with(auto r = root(t)) if(leaf(r) || blah < bar) {}

On Sunday, 6 November 2016 at 05:07:10 UTC, Andrei Alexandrescu wrote:
> if (auto variable = fun(); variable != 42) {
>   ...
> }
>
> Why does the word "variable" need to appear twice? It seems simpler to allow punctuation around existing syntax:
>
> // possible future D
> if ((auto variable = fun()) != 42) {
>   ...
> }

Avoiding stuttering is nice, but maybe it could be made a bit clearer if declarations were allowed for ref arguments and we used a named function:

alias let = (ref v) => v;

if (let(auto variable = fun()) != 42) {...}

The same feature allows tuple unpacking:

produceTuple.unpack(auto str, int i);

C# has argument declarations. Just an idea. I personally like the C++ syntax too as local variable names are usually short and it avoids brackets.

On Sunday, 6 November 2016 at 05:07:10 UTC, Andrei Alexandrescu wrote:
> // possible future D
> if ((auto variable = fun()) != 42) {
>   ...
> }
>
> Defining a variable in an expression wouldn't be allowed everywhere (but might be contemplated later as an possibility, which is a nice thing about this syntax).

I like it but it would have to require the parantheses, or you could get ambiguities like:

if (auto variable = noParensGetSomeT == true) {
    // is variable of type T or bool, if T can be implicitly cast?
}

> A more approachable thing to do is allow variable definitions in switch statements:
>
> switch (auto x = fun() { ... }
>
> It is surprising that doesn't work, which is a good argument in favor of the feature (removal of an undue limitation, rule of least astonishment etc).

This I can get behind, would start using it right away.

> Andrei

On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
>
> So I was thinking of a way of extending if statements that have declarations. The following being as example of the current use of if statements with declarations:
>
>     if(int* weDontPollute = someFunc())
>     {
>          // use weDontPollute
>     }
>
> That's great and all, but it only works by checking if the variable evaluates to true or false. Which is fine for a pointer but otherwise useless for anything else, like integers where zero is usually valid input (index for array). So currently the only way to do something like this in the language, that i've found, is to use a for statement.
>
>     for(int i = someFunc(); i >= 0;)
>     {
>         // use i
>
>         break;
>     }
>
> Not that ideal to use a for statement. It makes it hard to read and if the break condition isn't there it might very well be an infinite loop. So I was thinking of some sort of syntax like this:
>
>     if(int i = someFunc(); i >= 0)
>     {
>         // use i
>     }
> Thoughts on this sort of feature?

Hi, i refactored some templates[1] i had, so that you can provide your own predicate functions.

Variant 1 eager version:

auto when(alias pred, alias fun, T)(T type = T.init)

Variant 2 a lazy version, uses two templates:

auto when(alias pred, T)(T type = T.init)
auto call(alias fun, T)(T type)

check/modify the examples found here
[1] http://melpon.org/wandbox/permlink/g7V0gj4V7SGPjwqL

*OT is dpaste broken (cant seem to create new pastes) or is it just me?