www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If Statement with Declaration

reply sontung <sontung9901 gmail.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?
Jul 19 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
I like it.
Jul 19 2017
parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 19 July 2017 at 13:37:50 UTC, Adam D. Ruppe wrote:
 I like it.
Me too. I think this should also apply to switch and with statements. Perhaps while statements too.
Jul 19 2017
parent Nemanja Boric <4burgos gmail.com> writes:
On Wednesday, 19 July 2017 at 14:26:52 UTC, Dukc wrote:
 On Wednesday, 19 July 2017 at 13:37:50 UTC, Adam D. Ruppe wrote:
 I like it.
Me too. I think this should also apply to switch and with statements. Perhaps while statements too.
Right, C++17 has it also for a switch: ``` If init-statement is used, the switch statement is equivalent to { init_statement switch ( condition ) statement } ``` http://en.cppreference.com/w/cpp/language/switch
Jul 19 2017
prev sibling next sibling parent Nemanja Boric <4burgos gmail.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung 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?
This is included in C++17: http://en.cppreference.com/w/cpp/language/if ``` int demo() { if (auto it = m.find(10); it != m.end()) { return it->size(); } if (char buf[10]; std::fgets(buf, 10, stdin)) { m[0] += buf; } ... ```
Jul 19 2017
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung 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:

 [...]
I like it for C++17 and I like it for D. Atila
Jul 19 2017
prev sibling next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
I think I read this topic a couple of times here, and it went nowhere... Andrea
Jul 19 2017
parent Seb <seb wilzba.ch> writes:
On Wednesday, 19 July 2017 at 14:46:31 UTC, Andrea Fontana wrote:
 On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
I think I read this topic a couple of times here, and it went nowhere... Andrea
Well someone must take the initiative and submit a DIP for this feature. I miss it a lot too and would try to help this DIP.
Jul 19 2017
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung 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?
Achieving the same semantics as your example today would look like this { int i = someFunc(); if(i >= 0) { // use i } } The disadvantage being that it creates an extra level of nesting. I can see how this extra scope can discourage people from properly scoping their variables and this feature would eliminate the need for the extra scope. Also note that this example shows how this could be implemented using "syntax lowering". if( <declaration1> ; <desclaration2> ; ... ; <condition) { // } Becomes: { <declaration1>; <declaration2>; ... if(<condition>) { // ... } }
Jul 19 2017
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ---- It's slightly more verbose, but the meaning is clearer (arguable). It extends automatically to other control structures like `switch`. I wouldn't have this new `with (declaration)` have the magic lookup rules of the existing `with (expression)`. It would be a simpler tool that I'd probably use more than the existing `with`.
Jul 19 2017
next sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ---- It's slightly more verbose, but the meaning is clearer (arguable). It extends automatically to other control structures like `switch`. I wouldn't have this new `with (declaration)` have the magic lookup rules of the existing `with (expression)`. It would be a simpler tool that I'd probably use more than the existing `with`.
I really prefer this over if. This just made sense, just at a glance
Jul 19 2017
next sibling parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Wednesday, 19 July 2017 at 16:13:28 UTC, Swoorup Joshi wrote:
 On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ---- It's slightly more verbose, but the meaning is clearer (arguable). It extends automatically to other control structures like `switch`. I wouldn't have this new `with (declaration)` have the magic lookup rules of the existing `with (expression)`. It would be a simpler tool that I'd probably use more than the existing `with`.
I really prefer this over if. This just made sense, just at a glance
Me too. Would also allow with(char c = foo()) switch(x) { // use c } so no need to switch over the new declared variable, but still beeing able to use it there
Jul 19 2017
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 19 July 2017 at 16:13:28 UTC, Swoorup Joshi wrote:
 On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ---- It's slightly more verbose, but the meaning is clearer (arguable). It extends automatically to other control structures like `switch`. I wouldn't have this new `with (declaration)` have the magic lookup rules of the existing `with (expression)`. It would be a simpler tool that I'd probably use more than the existing `with`.
I really prefer this over if. This just made sense, just at a glance
Could also make 'with' behave like 'if', where it could apply to a block or just a single statement, i.e. // 'if' examples if(x) doSomething if(x) { doSomething } // 'with' examples with(auto x = 0) doSomething with(auto x = 0) { doSomething } This would automatically make it work with any statement: with(auto x = 0) if(x) { doSomething } with(auto x = 0) while(x) { doSomething } Could also do multiple with statements with(auto x = 0) with(auto y = 0) if(check(x, y)) { doSomething }
Jul 19 2017
parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Wednesday, 19 July 2017 at 16:49:38 UTC, Jonathan Marler wrote:

 This would automatically make it work with any statement:

 with(auto x = 0) if(x)
 {
    doSomething
 }

 with(auto x = 0) while(x)
 {
    doSomething
 }

 Could also do multiple with statements

 with(auto x = 0)
 with(auto y = 0)
 if(check(x, y))
 {
     doSomething
 }
Yes. That's exactly the idea. Only with this synax it's worth it.
Jul 19 2017
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 I'd prefer a new variant of `with`:

 ----
Looks much cleaner to me.
Jul 19 2017
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ----
It'd be nice to have either of these available in D, though I'd prefer the `with` one, since - `with` is currently not widely used - usually only for things like `switch (var) with (EnumName) {...}`; this would make `with` pull its own weight (so to speak) - I think it is way easier to read
Jul 20 2017
prev sibling parent Iakh <iaktakh gmail.com> writes:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
 On 07/19/2017 03:30 PM, sontung wrote:
 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?
I'd prefer a new variant of `with`: ---- with (int i = someFunc()) if (i >= 0) { // use i } ---- It's slightly more verbose, but the meaning is clearer (arguable). It extends automatically to other control structures like `switch`. I wouldn't have this new `with (declaration)` have the magic lookup rules of the existing `with (expression)`. It would be a simpler tool that I'd probably use more than the existing `with`.
I like "with" variant. Very mach like haskells "where". I believe it would be cool with expressions. Even can emulate named function arguments with (const skip_comments = false, const skip_empty_line = true) auto diff_result = diff(textA, textB, skip_comments, skip_empty_line);
Jul 20 2017
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/19/17 9:30 AM, sontung 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?
I really like the idea. Only thing I don't like is the possibility for abuse/confusion/errors: if(int i = someFunc(); j >= 0) // typo, or weird relationship, or just intentional obfuscation? It reminds me a bit of why we got rid of the comma operator. This is why I've liked suggestions in the past like: if((int i = foo()) >= 0) That is, you want to use 'if' on an expression while saving the expression, but the if is only looking at a property of that expression. Note this makes if(arr) (the correct meaning, that is ;) much more palatable: if((auto x = getArray()).length) Don't get me wrong, if this syntax is what gets this idea in, I'm fine with it. One possibility is to require usage of the declared variable in the condition. -Steve
Jul 19 2017
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer 
wrote:
 On 7/19/17 9:30 AM, sontung 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?
I really like the idea. Only thing I don't like is the possibility for abuse/confusion/errors: if(int i = someFunc(); j >= 0) // typo, or weird relationship, or just intentional obfuscation? It reminds me a bit of why we got rid of the comma operator. This is why I've liked suggestions in the past like: if((int i = foo()) >= 0) That is, you want to use 'if' on an expression while saving the expression, but the if is only looking at a property of that expression. Note this makes if(arr) (the correct meaning, that is ;) much more palatable: if((auto x = getArray()).length) Don't get me wrong, if this syntax is what gets this idea in, I'm fine with it. One possibility is to require usage of the declared variable in the condition. -Steve
I respectfully disagree with this. I recall many times where I want to declare variables that should be limited to the scope of the conditional block but aren't used in the condition itself, i.e { auto a = ...; auto b = ...; while(something) { // use a and b } } I imagine this feature allowing it to be rewritten as: while(auto a = ...; auto b = ...; something) { // use a and b }
Jul 19 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/19/17 11:47 AM, Jonathan Marler wrote:
 On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer wrote:
 On 7/19/17 9:30 AM, sontung 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?
I really like the idea. Only thing I don't like is the possibility for abuse/confusion/errors: if(int i = someFunc(); j >= 0) // typo, or weird relationship, or just intentional obfuscation? It reminds me a bit of why we got rid of the comma operator. This is why I've liked suggestions in the past like: if((int i = foo()) >= 0) That is, you want to use 'if' on an expression while saving the expression, but the if is only looking at a property of that expression. Note this makes if(arr) (the correct meaning, that is ;) much more palatable: if((auto x = getArray()).length) Don't get me wrong, if this syntax is what gets this idea in, I'm fine with it. One possibility is to require usage of the declared variable in the condition.
I respectfully disagree with this. I recall many times where I want to declare variables that should be limited to the scope of the conditional block but aren't used in the condition itself, i.e { auto a = ...; auto b = ...; while(something) { // use a and b } }
This is different. The variable exist outside the scope of the loop. This is more like a for-loop. Arguably, for-loops are better suited for this, and already support it: for(auto a = ..., b = ...; something;) An if statement runs once. There isn't an "exists for all the loops" for an if statement. So it's clean and neat to declare them in one place or the other. Only if you need to use it for the condition does the declaration have to be in the condition expression. But arguably, for loops can be (and have been) abused, so this isn't exactly new territory. Like I said, I'm OK with the proposal if that's what gets it done. -Steve
Jul 19 2017
prev sibling parent Cym13 <cpicard openmailbox.org> writes:
On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer 
wrote:
 On 7/19/17 9:30 AM, sontung wrote:
 [...]
I really like the idea. Only thing I don't like is the possibility for abuse/confusion/errors: if(int i = someFunc(); j >= 0) // typo, or weird relationship, or just intentional obfuscation? It reminds me a bit of why we got rid of the comma operator. This is why I've liked suggestions in the past like: if((int i = foo()) >= 0) That is, you want to use 'if' on an expression while saving the expression, but the if is only looking at a property of that expression. Note this makes if(arr) (the correct meaning, that is ;) much more palatable: if((auto x = getArray()).length) Don't get me wrong, if this syntax is what gets this idea in, I'm fine with it. One possibility is to require usage of the declared variable in the condition. -Steve
Now that I think about an extension of the comma makes more sense: if (int i=foo(), i<42) ... It is exactly the idea that we are trying to convey here (except that, deprecated comma aside, it doesn't work because of scope issues: i in i<42 is considered undefined). Given that the comma will never die and that it conveys exactly the idea I think think it should be prefered to the semi-colon.
Jul 19 2017
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
To be frank, I don't think that helping the programmer reduce the line count in their program by one line is worth further complicating the language.
Jul 19 2017
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/19/17 11:41 AM, Jack Stouffer wrote:
 On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
To be frank, I don't think that helping the programmer reduce the line count in their program by one line is worth further complicating the language.
It's 3 lines. One for the extra scope, one for the declaration, and one for the closing scope. Hm... just had an idea: auto propertyCheck(string condition, T)(T val) { static struct Result { T _value; opCast(B: bool)() { mixin("return _value " ~ condition ~ ";"); } alias _value this; } return Result(val); } if(auto x = someFunc().propertyCheck!" >= 0") { // use x as if it was the result of someFunc() } Has some drawbacks, for instance you may want to use the true booleanness of whatever T is inside the function. -Steve
Jul 19 2017
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 19 July 2017 at 15:41:18 UTC, Jack Stouffer wrote:
 On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
To be frank, I don't think that helping the programmer reduce the line count in their program by one line is worth further complicating the language.
As Steve mentioned, it's three lines and apart and it makes a huge difference if you have to review a large codebase. After all, syntactic sugar is one of the reasons why Python is so popular.
Jul 19 2017
prev sibling parent reply Iakh <iaktakh gmail.com> writes:
On Wednesday, 19 July 2017 at 15:41:18 UTC, Jack Stouffer wrote:
 On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
To be frank, I don't think that helping the programmer reduce the line count in their program by one line is worth further complicating the language.
It is not about reduce number of lines. It is about binding related things in one statement.
Jul 20 2017
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 20 July 2017 at 14:05:36 UTC, Iakh wrote:
 It is not about reduce number of lines. It is about binding
 related things in one statement.
Even so, it's already been shown in this thread that the same effect can be achieved via a block statement (doing exactly what it was designed for) or with a for loop. It's an small increase in terseness for a decrease in readability and an increase in complexity.
Jul 20 2017
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 20 July 2017 at 14:18:48 UTC, Jack Stouffer wrote:
 On Thursday, 20 July 2017 at 14:05:36 UTC, Iakh wrote:
 It is not about reduce number of lines. It is about binding
 related things in one statement.
Even so, it's already been shown in this thread that the same effect can be achieved via a block statement (doing exactly what it was designed for)
This decreases readability by splitting up parts that (the programmer wants to) semantically belong together.
 or with a for loop.
Which is a hack decreasing readability, because it works opposite to what one generally expects when reading a looping control structure.
 It's an small increase in terseness for a decrease in 
 readability and an increase in complexity.
W.r.t to the `with` solution only: It's a noticeable increase in readability for a minor increase in complexity.
Jul 20 2017
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jul 19, 2017 at 01:30:56PM +0000, sontung via Digitalmars-d wrote:
[...]
     if(int i = someFunc(); i >= 0)
     {
         // use i
     }
 Thoughts on this sort of feature?
I've been wanting such a feature for a long time now. Though I'd propose a different syntax: if ((int i = someFunc()) >= 0) { ... } T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
Jul 19 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, July 19, 2017 1:30:56 PM MDT sontung via Digitalmars-d 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?
I've wanted this for years, but based on previous conversations on the topic, I've assumed that we're never getting it. It sure wouldn't hurt my feelings though if someone put forth the time and effort to write a DIP for it. Maybe they could get it accepted. I don't know. - Jonathan M Davis
Jul 19 2017
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
I thought I remembered reading about this. But apparently, it was 
*exactly* this.

https://forum.dlang.org/post/dejodpslmjdovstdiwfz forum.dlang.org

And this is, ... well I guess I continue to have the same ideas :)

https://forum.dlang.org/post/oknvgb$2nr0$1 digitalmars.com
https://forum.dlang.org/post/nvi4t8$1750$1 digitalmars.com

I guess we should see another thread like this in another 8 months?

I remember reading a discussion about using with statements to do this 
earlier as well, but I can't find it.

-Steve
Jul 19 2017
parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Wednesday, 19 July 2017 at 20:42:33 UTC, Steven Schveighoffer 
wrote:
 I remember reading a discussion about using with statements to 
 do this earlier as well, but I can't find it.

 -Steve
I don't think this is the discussion you're talking about, but this does bring DIP 1005 to mind: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md Personally, I'm in favor of `with` for both variable declarations and imports. It's pretty intuitive semantically.
Jul 20 2017
prev sibling next sibling parent Guillaume Piolat <contact spam.com> writes:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
 Thoughts on this sort of feature?
This doesn't enable anything new, and breaks readability conventions.
Jul 20 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/19/2017 09:30 AM, sontung wrote:
[snip]

This post: 
http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw forum.dlang.org seems 
to be identical to one on November 3, 2016: 
http://forum.dlang.org/post/dejodpslmjdovstdiwfz forum.dlang.org.

Hat tip for persistence!

Regarding the feature itself: it seems to be fancied by the new 
languages, and C++ added it, too. I must be old school because I don't 
see much benefit in it, and don't quite find it natural. It's bizarre 
even lexically: "If the following ... oh wait let me insert some stuff 
... as I was saying, if the following condition happens..." Conversely, 
I find the let/letrec syntax in functional languages a bit more convivial.

The suggested enhancement of "with" seems to sit well on the page:

with (auto x = fun())
if (x > 0)
{
    ...
}

and offers some additional flexibility such as:

if (!r.empty)
with (auto x = r.front)
{
    ...
}

and also "for free" variations such as:

while (!r.empty)
with (auto x = r.front)
{
    ...
}

and

with (auto r = makeMeARange())
if (!r.empty)
{
    ...
}

Of course there's always the opportunity to go bananas :o).

with (auto r = makeMeARange)
if (!r.empty)
with (auto x = r.front)
{
    ...
}


Andrei
Jul 21 2017
next sibling parent reply Johan Engelen <j j.nl> writes:
On Friday, 21 July 2017 at 21:32:48 UTC, Andrei Alexandrescu 
wrote:
 
 It's bizarre even lexically: "If the following ... oh wait let 
 me insert some stuff ... as I was saying, if the following 
 condition happens..."
(excuse me for muddying the waters) We do have a construct like that already: ``` static if (is(E V == enum)) { // this inserts "V" V v; } ``` -Johan
Jul 21 2017
parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
 We do have a construct like that already:
 ```
 static if (is(E V == enum)) { // this inserts "V"
    V v;
 }
 ```
Yes, but this is a bit different as the goal is to avoid repeating V (as it may be complex). Repeating a local variable name (using e.g. `with...if`) isn't a problem as the variable should have a short identifier. With the above `is` expression it's unavoidable to have a test and a declaration combined. That said, the syntax could be much clearer: static if (is(E == enum; alias V)) { // this inserts "V" V v; } This syntax clearly separates the test from the declaration, and makes the declaration obvious due to the alias keyword. The test comes first as it logically should, as the alias is not being used until the following statement. It extends to the other `is` expression forms: is(T; alias A) is(T : U; alias A) is(T : U!V, U, V; alias A) is(T == U!V, U, V; alias A) (http://dlang.org/spec/expression.html#IsExpression) Whenever I want to use the identifier variant I always end up checking the spec. When I see it in code I usually have to stop what I was thinking about to parse the `is` expression.
Jul 24 2017
next sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
 On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
 static if (is(E V == enum)) { // this inserts "V"
    V v;
 }
 ```
Yes, but this is a bit different as the goal is to avoid repeating V
Sigh. Repeating E. (unintentional ironic mistake)
Jul 24 2017
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
 static if (is(E == enum; alias V)) { // this inserts "V"
    V v;
 }

 The test comes first as it logically should, as the alias is 
 not being used until the following statement.
Hmm, it can be used in the test: is(Abc U : U*) is(AA A : A[B], B : int) is(AA T : T[U], U : const char[]) So the alias part would come first instead: is(alias U; Abc : U*) is(alias A; AA : A[B], B : int) is(alias T; AA : T[U], U : const char[]) Note: The spec page needs to use CamelCase for types (abc -> Abc, bar -> Bar), especially as the construct is difficult to read anyway. Maybe I'll do this soon. (I think other parts of the spec contravene this too).
Jul 24 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, July 21, 2017 17:32:48 Andrei Alexandrescu via Digitalmars-d 
wrote:
 On 07/19/2017 09:30 AM, sontung wrote:
 [snip]

 This post:
 http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw forum.dlang.org seems
 to be identical to one on November 3, 2016:
 http://forum.dlang.org/post/dejodpslmjdovstdiwfz forum.dlang.org.

 Hat tip for persistence!

 Regarding the feature itself: it seems to be fancied by the new
 languages, and C++ added it, too. I must be old school because I don't
 see much benefit in it, and don't quite find it natural. It's bizarre
 even lexically: "If the following ... oh wait let me insert some stuff
 ... as I was saying, if the following condition happens..." Conversely,
 I find the let/letrec syntax in functional languages a bit more convivial.
I would have thought that it was a fairly obvious extension given how for loops work (especially since you can already declare variables in if statements; you just can't do it and then use something else for the condition), and it's less verbose than doing something with with, though I suppose that getting with to work like this would be better than nothing. It does seem unnecessarily verbose in comparison though. - Jonathan M Davis
Jul 21 2017
prev sibling parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Friday, 21 July 2017 at 21:32:48 UTC, Andrei Alexandrescu 
wrote:
 with (auto r = makeMeARange)
 if (!r.empty)
 with (auto x = r.front)
 {
    ...
 }


 Andrei
I'm being real nitpicky, but this in particular just seems like a slightly worse way to write with (auto r = makeMeARange) if (!r.empty) { auto x = r.front; ... } But yeah, it's cool construct that lends itself to pretty neat chaining.
Jul 24 2017