www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If Statement with Declaration

reply Jerry <hurricane hereiam.com> writes:
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?
Nov 03 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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:

 [...]
Just Introduce another block { int i = someFunc(); if (i >= 0) { ... } } // i is not visible here
Nov 03 2016
next sibling parent reply mogu <mogucpp 163.com> writes:
On Thursday, 3 November 2016 at 22:32:17 UTC, Stefan Koch wrote:
 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:

 [...]
Just Introduce another block { int i = someFunc(); if (i >= 0) { ... } } // i is not visible here
Introducing a block is not intuitive and cause an identation. As a reference, C++17 has adopted a proposal about this, and extended to switch: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
Nov 03 2016
parent ixid <adamsibson hotmail.com> writes:
On Friday, 4 November 2016 at 00:04:28 UTC, mogu wrote:
 Introducing a block is not intuitive and cause an identation.
How is using a block to produce a sub-scope not intuitive? That's using a standard feature to do exactly what it is supposed to do.
Nov 04 2016
prev sibling parent reply Superstar64 <Hexagonalstar64 gmail.com> writes:
On Thursday, 3 November 2016 at 22:32:17 UTC, Stefan Koch wrote:
 Just Introduce another block
 {
   int i = someFunc();
   if (i >= 0) { ... }
 }
 // i is not visible here
That adds 2 indention levels after formatting. Unfortunately this doesn't work: --- { int i = someFunc(); if (i >= 0): //your code here } // i is not visible here ---
Nov 04 2016
parent reply Andrea Fontana <nospam example.com> writes:
On Friday, 4 November 2016 at 13:38:30 UTC, Superstar64 wrote:
 On Thursday, 3 November 2016 at 22:32:17 UTC, Stefan Koch wrote:
 Just Introduce another block
 {
   int i = someFunc();
   if (i >= 0) { ... }
 }
 // i is not visible here
That adds 2 indention levels after formatting. Unfortunately this doesn't work: --- { int i = someFunc(); if (i >= 0): //your code here } // i is not visible here ---
If you don't like indentation you can simply ignore it or you can use old goto :) { int i = someFunc(); if (i < 0) goto outer; // your code here } outer: // i is not visibe here
Nov 04 2016
parent Nick Treleaven <nick geany.org> writes:
On Friday, 4 November 2016 at 13:56:57 UTC, Andrea Fontana wrote:
 If you don't like indentation you can simply ignore it or you 
 can use old goto :)

 {
    int i = someFunc();
    if (i < 0) goto outer;
    // your code here
 }
 outer:
BTW there is a trick to avoid goto+label: switch (true) { default: int i = someFunc(); if (i < 0) break; ... } If code after goto is long, the reader has to search for the label. With switch/break, the reader knows the current scope is just skipped, no need to interrupt reading of lines. We could allow omitting the condition and default label: switch { int i = someFunc(); if (i < 0) break; ... } That would encourage the pattern to be used instead of the 'triangle if' pattern - the rationale for breakable blocks: https://issues.dlang.org/show_bug.cgi?id=8622
Nov 04 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/3/16 6:29 PM, 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?
Hm... what about something like: struct BoolCond(T, string cond) { T val; bool opCast(B)() if(is(B == bool)) { return mixin("val " ~ cond); } } auto boolcond(string cond, T)(T val) { return BoolCond!(T, cond)(val); } if(auto i = someFunc.boolcond!(">= 0")) { ... // use i } -Steve
Nov 04 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/4/16 10:10 AM, Steven Schveighoffer wrote:
 On 11/3/16 6:29 PM, 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?
Hm... what about something like: struct BoolCond(T, string cond) { T val; bool opCast(B)() if(is(B == bool)) { return mixin("val " ~ cond); }
Of course, I missed this: alias val this; -Steve
Nov 04 2016
prev sibling parent reply Jerry <hurricane hereiam.com> writes:
On Friday, 4 November 2016 at 14:10:51 UTC, Steven Schveighoffer 
wrote:
 On 11/3/16 6:29 PM, 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?
Hm... what about something like: struct BoolCond(T, string cond) { T val; bool opCast(B)() if(is(B == bool)) { return mixin("val " ~ cond); } } auto boolcond(string cond, T)(T val) { return BoolCond!(T, cond)(val); } if(auto i = someFunc.boolcond!(">= 0")) { ... // use i } -Steve
Well that's just a basic case, what if you want more than one condition. Using "&&" for example, or a condition along with another value that's in the scope. void otherFunc(int input) { if(auto i = someFunc.boolcond!(">= input")) // --- error { ... // use i } } Then you need another work around for something like this: if(int value; auto i = someFunc(&value)) { // ... }
Nov 04 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/4/16 11:27 AM, Jerry wrote:
 On Friday, 4 November 2016 at 14:10:51 UTC, Steven Schveighoffer wrote:
 Hm... what about something like:

 struct BoolCond(T, string cond)
 {
    T val;
    bool opCast(B)() if(is(B == bool))
    {
      return mixin("val " ~ cond);
    }
 }

 auto boolcond(string cond, T)(T val)
 {
    return BoolCond!(T, cond)(val);
 }

 if(auto i = someFunc.boolcond!(">= 0"))
 {
    ... // use i
 }
Well that's just a basic case, what if you want more than one condition. Using "&&" for example, or a condition along with another value that's in the scope.
It's just a strawman type, I'm sure there's ways to handle these things, I just didn't put a lot of effort into all the cases. But really it's just syntax to separate the bool check from the value itself. You can get more elaborate if you want with the comparison. The difficult thing is having a type that you use normally, but that when you use in an if statement, it gives what you want. And declaring that type in the if clause itself (which is allowed in restricted circumstances). This also isn't exactly ideal for things like int, as if(i) would now be unexpected.
 Then you need another work around for something like this:

 if(int value; auto i = someFunc(&value))
 {
    // ...
 }
I thought you could only declare variables in the first clause? In any case, I think Stefan really has the best answer: {int value; if(auto i = someFunc(&value)) { // ... }} Sure, it doesn't look great. But my expectation is that your proposal doesn't pull enough weight to be integrated into the language. There are enough ways to solve this problem that don't involve language changes. -Steve
Nov 04 2016
parent reply Jerry <hurricane hereiam.com> writes:
On Friday, 4 November 2016 at 16:15:21 UTC, Steven Schveighoffer 
wrote:
 It's just a strawman type, I'm sure there's ways to handle 
 these things, I just didn't put a lot of effort into all the 
 cases.

 But really it's just syntax to separate the bool check from the 
 value itself. You can get more elaborate if you want with the 
 comparison. The difficult thing is having a type that you use 
 normally, but that when you use in an if statement, it gives 
 what you want. And declaring that type in the if clause itself 
 (which is allowed in restricted circumstances).

 This also isn't exactly ideal for things like int, as if(i) 
 would now be unexpected.
It is just a basic type but ultimately you will probably need more than one type with a different way of operating to get the same behavior. That and having part of the code as a string which makes it harder to read and no syntax highlighting for the code in text editors/ides. What do you mean if(i) would be unexpected?
 I thought you could only declare variables in the first clause?

 In any case, I think Stefan really has the best answer:

 {int value; if(auto i = someFunc(&value))
 {
     // ...
 }}

 Sure, it doesn't look great. But my expectation is that your 
 proposal doesn't pull enough weight to be integrated into the 
 language. There are enough ways to solve this problem that 
 don't involve language changes.

 -Steve
It follows the same rules for an if statement condition which an if statement allows "if(auto i = foo())". It's syntactic sugar, most of the existing language features don't serve a functional purpose. They simply serve to simplify another syntax. Every "foreach" statement could be written as a for-statement. Every for-statement could be written as a while-statement. And so on so forth. It doesn't add anything that new either. It follows the same syntax as a for-statement. It's not that big of a language feature, it's just a small syntactic change, which comes down to. Is this easier to read compared to this. {int value; if(auto i = someFunc(&value)) { // ... }} vs. if(int value; auto i = someFunc(&value)) { // ... } 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.
Nov 04 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/4/16 1:46 PM, Jerry wrote:
 On Friday, 4 November 2016 at 16:15:21 UTC, Steven Schveighoffer wrote:
 It's just a strawman type, I'm sure there's ways to handle these
 things, I just didn't put a lot of effort into all the cases.

 But really it's just syntax to separate the bool check from the value
 itself. You can get more elaborate if you want with the comparison.
 The difficult thing is having a type that you use normally, but that
 when you use in an if statement, it gives what you want. And declaring
 that type in the if clause itself (which is allowed in restricted
 circumstances).

 This also isn't exactly ideal for things like int, as if(i) would now
 be unexpected.
It is just a basic type but ultimately you will probably need more than one type with a different way of operating to get the same behavior. That and having part of the code as a string which makes it harder to read and no syntax highlighting for the code in text editors/ides. What do you mean if(i) would be unexpected?
I mean something like: if(auto i = func.cond("==0")) { assert(i == 0); if(i) { writeln("oops!"); } }
 Sure, it doesn't look great. But my expectation is that your proposal
 doesn't pull enough weight to be integrated into the language. There
 are enough ways to solve this problem that don't involve language
 changes.
It follows the same rules for an if statement condition which an if statement allows "if(auto i = foo())".
Right, I'm just saying syntax changes like this generally need a high motivation and perceived improvement to justify the undertaking. For instance, we have trusted escapes via this construct: auto foo = (() trusted => systemFunc(x))(); It's ugly, verbose, confusing. But it works, and it works today. I'd much rather have this look like: auto foo = trusted(systemFunc(x)); or something similar, but how much benefit are we going to get from this? Is it going to change productivity? Is it going to make code so much easier to write that the time taken to implement was worth it? I don't know the answer to that. Often the answer to requests for such improvements is "yeah, but you can just do it this way, and that's good enough". That's all I'm trying to say.
 It's syntactic sugar, most of the existing language features don't serve
 a functional purpose. They simply serve to simplify another syntax.
 Every "foreach" statement could be written as a for-statement. Every
 for-statement could be written as a while-statement. And so on so forth.
 It doesn't add anything that new either. It follows the same syntax as a
 for-statement.
Existence of current sugar is not justification of adding more. Those already exist (and BTW have existed for a long long time), there is no cost to continuing to have them. There is a cost to adding new features, that we must weigh against the benefits. One thing that could work in your favor is if the change is easy to implement in the compiler. That I definitely don't know the answer to.
 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
Nov 04 2016
parent Jerry <hurricane hereiam.com> writes:
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) { }}
Nov 04 2016
prev sibling next sibling parent reply Matthias Bentrup <matthias.bentrup googlemail.com> writes:
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
     if(int i = someFunc(); i >= 0)
     {
         // use i
     }
 Thoughts on this sort of feature?
I would prefer the syntax if( (int i = someFunc()) >= 0 ) { // use i } as this matches the already existing assignment expression syntax if you pull the declaration out of the if expression.
Nov 04 2016
parent reply Jerry <hurricane hereiam.com> writes:
On Friday, 4 November 2016 at 14:16:44 UTC, Matthias Bentrup 
wrote:
 On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
     if(int i = someFunc(); i >= 0)
     {
         // use i
     }
 Thoughts on this sort of feature?
I would prefer the syntax if( (int i = someFunc()) >= 0 ) { // use i } as this matches the already existing assignment expression syntax if you pull the declaration out of the if expression.
Well you can argue the "if( init ; condition )" syntax matches "for( init ; condition ; update)", minus the "update" section. It's cleaner as well as you don't need an extra set of parenthesizes. As well that sort of syntax would allow multiple declaration. Which I'm not sure that's desired, it becomes increasingly messy. if((int i = someFunc()) >= 0 && (int j = otherFunc()) >= 0) { } You also can't use the declaration as input for someFunc(): if(int i; someFunc(&i) >= 0) { }
Nov 04 2016
parent reply Adrian Matoga <dlang.spam matoga.info> writes:
On Friday, 4 November 2016 at 15:34:00 UTC, Jerry wrote:
 On Friday, 4 November 2016 at 14:16:44 UTC, Matthias Bentrup 
 wrote:
 On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
     if(int i = someFunc(); i >= 0)
     {
         // use i
     }
 Thoughts on this sort of feature?
I would prefer the syntax if( (int i = someFunc()) >= 0 ) { // use i } as this matches the already existing assignment expression syntax if you pull the declaration out of the if expression.
Well you can argue the "if( init ; condition )" syntax matches "for( init ; condition ; update)", minus the "update" section.
You've just answered your own question: for (int i = someFunc(); i >= 0; ) { // use i break; }
Nov 04 2016
parent Jerry <hurricane hereiam.com> writes:
On Friday, 4 November 2016 at 18:05:51 UTC, Adrian Matoga wrote:
 On Friday, 4 November 2016 at 15:34:00 UTC, Jerry wrote:
 On Friday, 4 November 2016 at 14:16:44 UTC, Matthias Bentrup 
 wrote:
 On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
     if(int i = someFunc(); i >= 0)
     {
         // use i
     }
 Thoughts on this sort of feature?
I would prefer the syntax if( (int i = someFunc()) >= 0 ) { // use i } as this matches the already existing assignment expression syntax if you pull the declaration out of the if expression.
Well you can argue the "if( init ; condition )" syntax matches "for( init ; condition ; update)", minus the "update" section.
You've just answered your own question: for (int i = someFunc(); i >= 0; ) { // use i break; }
Yes, it was one of the examples I gave in the first post. Reason not to use that is, if you forget "break" you are probably going to have an infinite loop. As well you can't use "else" with a for statement.
Nov 04 2016
prev sibling next sibling parent Jerry <Kickupx gmail.com> writes:
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
 Thoughts on this sort of feature?
Love your name, Jerry ;) Maybe something like this psuedo code: struct Condition(T) { Condition(T val, bool cond) { m_val = val; m_cond = cond; } bool opCast(T)() if(is(T == bool)) { return m_cond; } alias m_val this; private: T m_val; bool m_cond; } auto cond(T v, bool cond) { return Condition!T(v, cond); } Usage: int v = 5; if(v = cond(v, v > 4) { writeln("Happy coding"); } Just notice I am not proud of that T.init.
Nov 04 2016
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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).
This is already possible in library code. See here: https://github.com/AndrejMitrovic/minilib/blob/510460ff1381f765a66aa3b8f8f6d7e95b4597b9/src/minilib/core/types.d#L88-L137 One could come up with a helper function that encodes the condition which is moved into the opCast method. This should be trivial to implement.
Nov 04 2016
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04.11.2016 21:03, Andrej Mitrovic wrote:
 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).
This is already possible in library code. See here: https://github.com/AndrejMitrovic/minilib/blob/510460ff1381f765a66aa3b8f8f6d7e95b4597b9/src/minilib/core/types.d#L88-L137
Not worth the IFTI-induced template bloat IMHO.
Nov 04 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Nov 05 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)
Nov 05 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 05 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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
Nov 05 2016
prev sibling next sibling parent Enamex <enamex+d outlook.com> writes:
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) {}
Nov 06 2016
prev sibling next sibling parent Nick Treleaven <nick geany.org> writes:
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.
Nov 07 2016
prev sibling parent Anonymouse <asdf asdf.net> writes:
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
Nov 07 2016
prev sibling parent ArturG <var.spool.mail700 gmail.com> writes:
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?
Nov 07 2016