digitalmars.D - If Statement with Declaration
- sontung (26/26) Jul 19 2017 So I was thinking of a way of extending if statements that have
- Adam D. Ruppe (2/3) Jul 19 2017 I like it.
- Dukc (3/4) Jul 19 2017 Me too. I think this should also apply to switch and with
- Nemanja Boric (10/14) Jul 19 2017 Right, C++17 has it also for a switch:
- Nemanja Boric (9/36) Jul 19 2017 This is included in C++17:
- Atila Neves (3/7) Jul 19 2017 I like it for C++17 and I like it for D.
- Andrea Fontana (4/5) Jul 19 2017 I think I read this topic a couple of times here, and it went
- Seb (4/9) Jul 19 2017 Well someone must take the initiative and submit a DIP for this
- Jonathan Marler (30/57) Jul 19 2017 Achieving the same semantics as your example today would look
- ag0aep6g (13/20) Jul 19 2017 I'd prefer a new variant of `with`:
- Swoorup Joshi (3/25) Jul 19 2017 I really prefer this over if. This just made sense, just at a
- Dominikus Dittes Scherkl (9/38) Jul 19 2017 Me too.
- Jonathan Marler (33/62) Jul 19 2017 Could also make 'with' behave like 'if', where it could apply to
- Dominikus Dittes Scherkl (2/18) Jul 19 2017 Yes. That's exactly the idea. Only with this synax it's worth it.
- jmh530 (2/4) Jul 19 2017 Looks much cleaner to me.
- Moritz Maxeiner (7/22) Jul 20 2017 It'd be nice to have either of these available in D, though I'd
- Iakh (8/30) Jul 20 2017 I like "with" variant. Very mach like haskells "where". I believe
- Steven Schveighoffer (18/49) Jul 19 2017 I really like the idea. Only thing I don't like is the possibility for
- Jonathan Marler (20/72) Jul 19 2017 I respectfully disagree with this. I recall many times where I
- Steven Schveighoffer (13/87) Jul 19 2017 This is different. The variable exist outside the scope of the loop.
- Cym13 (9/29) Jul 19 2017 Now that I think about an extension of the comma makes more sense:
- Jack Stouffer (4/5) Jul 19 2017 To be frank, I don't think that helping the programmer reduce the
- Steven Schveighoffer (22/28) Jul 19 2017 It's 3 lines. One for the extra scope, one for the declaration, and one
- Seb (5/10) Jul 19 2017 As Steve mentioned, it's three lines and apart and it makes a
- Iakh (3/8) Jul 20 2017 It is not about reduce number of lines. It is about binding
- Jack Stouffer (6/8) Jul 20 2017 Even so, it's already been shown in this thread that the same
- Moritz Maxeiner (8/17) Jul 20 2017 This decreases readability by splitting up parts that (the
- H. S. Teoh via Digitalmars-d (11/16) Jul 19 2017 I've been wanting such a feature for a long time now. Though I'd propose
- Jonathan M Davis via Digitalmars-d (6/32) Jul 19 2017 I've wanted this for years, but based on previous conversations on the
- Steven Schveighoffer (10/10) Jul 19 2017 I thought I remembered reading about this. But apparently, it was
- Olivier FAURE (7/10) Jul 20 2017 I don't think this is the discussion you're talking about, but
- Guillaume Piolat (3/4) Jul 20 2017 This doesn't enable anything new, and breaks readability
- Andrei Alexandrescu (45/45) Jul 21 2017 On 07/19/2017 09:30 AM, sontung wrote:
- Johan Engelen (10/14) Jul 21 2017 (excuse me for muddying the waters)
- Nick Treleaven (23/29) Jul 24 2017 Yes, but this is a bit different as the goal is to avoid
- Nick Treleaven (2/9) Jul 24 2017 Sigh. Repeating E. (unintentional ironic mistake)
- Nick Treleaven (13/18) Jul 24 2017 Hmm, it can be used in the test:
- Jonathan M Davis via Digitalmars-d (9/22) Jul 21 2017 I would have thought that it was a fairly obvious extension given how fo...
- Olivier FAURE (12/19) Jul 24 2017 I'm being real nitpicky, but this in particular just seems like a
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
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:Thoughts on this sort of feature?I like it.
Jul 19 2017
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
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: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/switchI like it.Me too. I think this should also apply to switch and with statements. Perhaps while statements too.
Jul 19 2017
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
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
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
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: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.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
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
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
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:On 07/19/2017 03:30 PM, sontung wrote:I really prefer this over if. This just made sense, just at a glanceSo 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
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: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 thereOn 07/19/2017 03:30 PM, sontung wrote:I really prefer this over if. This just made sense, just at a glanceSo 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
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: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 }On 07/19/2017 03:30 PM, sontung wrote:I really prefer this over if. This just made sense, just at a glanceSo 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
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
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
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:On 07/19/2017 03:30 PM, sontung wrote: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 readSo 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 } ----
Jul 20 2017
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:On 07/19/2017 03:30 PM, sontung wrote: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);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 20 2017
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
On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer wrote:On 7/19/17 9:30 AM, sontung wrote: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 }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
On 7/19/17 11:47 AM, Jonathan Marler wrote:On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer wrote: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. -SteveOn 7/19/17 9:30 AM, sontung wrote: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 } }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.
Jul 19 2017
On Wednesday, 19 July 2017 at 15:39:02 UTC, Steven Schveighoffer wrote:On 7/19/17 9:30 AM, sontung wrote: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.[...]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
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
On 7/19/17 11:41 AM, Jack Stouffer wrote:On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote: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. -SteveThoughts 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
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: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.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
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:It is not about reduce number of lines. It is about binding related things in one statement.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 20 2017
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
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:This decreases readability by splitting up parts that (the programmer wants to) semantically belong together.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.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
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
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
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
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. -SteveI 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
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
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
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
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
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:Sigh. Repeating E. (unintentional ironic mistake)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
Jul 24 2017
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
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
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) { ... } AndreiI'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