C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch

What do you think about it, can we have something similar to that.
Maybe something like this:


int func() return 5;

with(auto x = func()) if (condition(x))
    do_something_with(x);
else
    do_something_else_with(x);

On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
> C++17 will have this feature:
> https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
>
> What do you think about it, can we have something similar to that.
> Maybe something like this:
>
>
> int func() return 5;
>
> with(auto x = func()) if (condition(x))
>     do_something_with(x);
> else
>     do_something_else_with(x);

this would be rewrite to

int func() return 5;

{
    auto x = func();
    if (condition(x))
        do_something_with(x);
    else
        do_something_else_with(x);
}

On Tuesday, 15 August 2017 at 19:04:32 UTC, Daniel Kozak wrote:
> On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
>> C++17 will have this feature:
>> int func() return 5;
>>
>> with(auto x = func()) if (condition(x))
>>     do_something_with(x);
>> else
>>     do_something_else_with(x);
>
> this would be rewrite to
>
> int func() return 5;
>
> {
>     auto x = func();
>     if (condition(x))
>         do_something_with(x);
>     else
>         do_something_else_with(x);
> }

int func() { return 5; }

On Tuesday, 15 August 2017 at 19:24:00 UTC, Daniel Kozak wrote:
>
> int func() { return 5; }
int func() return 5;

was a typo in all my previous posts :)

On 08/15/2017 08:55 PM, Daniel Kozak wrote:
> C++17 will have this feature:
> https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch 
> 
> 
> What do you think about it, can we have something similar to that.
> Maybe something like this:
> 
> 
> int func() return 5;
> 
> with(auto x = func()) if (condition(x))
>      do_something_with(x);
> else
>      do_something_else_with(x);

Previous discussion:
http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw@forum.dlang.org

Andrei doesn't like the C++ way, but he seems to be ok with the `with` way:
http://forum.dlang.org/post/oktru0$159b$1@digitalmars.com

Walter didn't comment.

I think this has a good chance of getting in, but someone will have to write a DIP and implement it.

On Tuesday, 15 August 2017 at 20:17:40 UTC, ag0aep6g wrote:
> On 08/15/2017 08:55 PM, Daniel Kozak wrote:
>> C++17 will have this feature:
>> https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
>> 
>> 
>> What do you think about it, can we have something similar to that.
>> Maybe something like this:
>> 
>> 
>> int func() return 5;
>> 
>> with(auto x = func()) if (condition(x))
>>      do_something_with(x);
>> else
>>      do_something_else_with(x);
>
> Previous discussion:
> http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw@forum.dlang.org
>
> Andrei doesn't like the C++ way, but he seems to be ok with the `with` way:
> http://forum.dlang.org/post/oktru0$159b$1@digitalmars.com
>
> Walter didn't comment.
>
> I think this has a good chance of getting in, but someone will have to write a DIP and implement it.

I wouldn't mind writing a DIP but I haven't seen enough benefit to warrant the change yet.

I grep'd for 'if' statements in a couple phobos modules and didn't see too many places it could be used there.

The syntax does remind me of Andrei's scoped imports proposal:

with(import std.stdio : File) void foo(File file)
{
    //...
}

I think if that proposal gets accepted it would be a natural extension to allow both imports and declarations inside a 'with' expression and it would get more exposure/usage among the greater community.  Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer.  So I guess it depends on whether or not you think it would gain widespread adoption?

On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:

> Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer.

That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention. As a general rule, if it's being added to C++, it's probably a bad idea.

On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
> On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:
>
>> Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer.
>
> That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention.

+1, though I'd go for bug-fixing over IDEs.  It was ridiculous that we were spending time discussing a marginal feature like scoping imports for module-scope template constraints, ie DIP 1005, when normal scoped and selective imports are not used that much yet, as evidenced by latent bugs like this symbol leak:

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

> As a general rule, if it's being added to C++, it's probably a bad idea.

Lol. :D

On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
>> That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention.
>
> +1, though I'd go for bug-fixing over IDEs.

I like that.  Feature freeze D until *all* bug reports are closed.
While that would mean no more features for several years, I think it would benefit the language in the long run, both internally (less discussions about incorrect behavior) and externally (D is a mature and stable language).

On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher wrote:
>
> I like that.  Feature freeze D until *all* bug reports are closed.
> While that would mean no more features for several years, I think it would benefit the language in the long run, both internally (less discussions about incorrect behavior) and externally (D is a mature and stable language).

Seems a bit much. How about new features can only be added in one of every N releases (Where N > 1)?