www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++17 Init statement for if/switch

reply Daniel Kozak <kozzi11 gmail.com> writes:
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);
Aug 15
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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); }
Aug 15
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
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; }
Aug 15
parent Daniel Kozak <kozzi11 gmail.com> writes:
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 :)
Aug 15
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
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-st
tement-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.
Aug 15
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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?
Aug 15
parent reply bachmeier <no spam.net> writes:
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.
Aug 15
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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
Aug 16
parent reply Guillaume Boucher <guillaume.boucher.d gmail.com> writes:
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).
Aug 16
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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)?
Aug 16
prev sibling parent Sad panda <sad panda.net> writes:
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher 
wrote:
 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).
You'd see a fork.
Aug 16
prev sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
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. As a general rule, if it's being added to C++, it's probably a bad idea.
There are two thinks of c++ that I miss a little on D: - Structured binding - Uniform initialization But in general, I agreed with you.
Aug 16
parent reply Enamex <enamex+d outlook.com> writes:
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
 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. As a general rule, if it's being added to C++, it's probably a bad idea.
There are two thinks of c++ that I miss a little on D: - Structured binding - Uniform initialization But in general, I agreed with you.
Initialization in D is pretty uniform now though. What corners am I missing? It's usually: <type-or-infer> name = <constructor>(args); Structured bindings... I think C++ did it badly, actually. They had the {...} syntax fr object construction that worked everywhere and using the same for deconstruction would've allowed for quite natural tuples, which manifest almost as language-level constructs by then (with the help of 'auto' in template parameters).
Aug 17
parent SrMordred <patric.dexheimer gmail.com> writes:
On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:
 On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
 On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
 [...]
There are two thinks of c++ that I miss a little on D: - Structured binding - Uniform initialization But in general, I agreed with you.
Initialization in D is pretty uniform now though. What corners am I missing? It's usually: <type-or-infer> name = <constructor>(args); Structured bindings... I think C++ did it badly, actually. They had the {...} syntax fr object construction that worked everywhere and using the same for deconstruction would've allowed for quite natural tuples, which manifest almost as language-level constructs by then (with the help of 'auto' in template parameters).
Nothing too serious, just miss somethings like: void add_vec( vec2 a, vec2 b ); add_vec( {10,20}, {20,30} );
Aug 17