www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP1001: DoExpression

reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: DIP1001: DoExpression

--eAfevbd1HoFFbWqMNXT4XdpS0OBFglIRb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

Abstract
--------

A DoExpression do(x,y,z) is exactly equivalent to a CommaExpression
(x,y,z), but doesn't emit a deprecation warning.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

First community DIP has just landed the review queue. Please express
your opinion and suggestions - it will all be taken into consideration
when the formal review time comes.


--eAfevbd1HoFFbWqMNXT4XdpS0OBFglIRb--
Sep 03 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/09/2016 2:20 AM, Dicebot wrote:
 DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

 Abstract
 --------

 A DoExpression do(x,y,z) is exactly equivalent to a CommaExpression
 (x,y,z), but doesn't emit a deprecation warning.

 ==============================================

 First community DIP has just landed the review queue. Please express
 your opinion and suggestions - it will all be taken into consideration
 when the formal review time comes.
I propose a slight change: do(x, y, return z) To make it clear that z is the one being returned. Otherwise how does somebody who isn't familiar with D know what it is doing?
Sep 03 2016
parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 14:25:49 UTC, rikki cattermole 
wrote:
 I propose a slight change:
 do(x, y, return z)
Hmm, I suppose I should mention one other motivation behind this DIP: I really like to avoid using the 'return' keyword inside expressions, because I find it visually confusing - hear me out here - When you're reading a function and trying to understand its control flow, one of the main elements you're searching for is all the places the function can return from. If the code has a lot of anonymous functions with return statements this can really slow down the process as you have to more carefully inspect every return to see if it's a 'real' return or inside an anonymous function. Also, in case it wasn't obvious, the do() syntax was inspired by Clojure: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
Sep 03 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/09/2016 2:42 AM, Cauterite wrote:
 On Saturday, 3 September 2016 at 14:25:49 UTC, rikki cattermole wrote:
 I propose a slight change:
 do(x, y, return z)
Hmm, I suppose I should mention one other motivation behind this DIP: I really like to avoid using the 'return' keyword inside expressions, because I find it visually confusing - hear me out here - When you're reading a function and trying to understand its control flow, one of the main elements you're searching for is all the places the function can return from. If the code has a lot of anonymous functions with return statements this can really slow down the process as you have to more carefully inspect every return to see if it's a 'real' return or inside an anonymous function. Also, in case it wasn't obvious, the do() syntax was inspired by Clojure: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
I may dislike not using return but please consider at the very least using ; instead of , for the last element do(x, y ; z). Just something to hint that the last one is special. Truth be told I don't want to be spending time figuring out syntax at e.g. 3am which is not core to D or c like languages.
Sep 03 2016
parent Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 14:47:50 UTC, rikki cattermole 
wrote:
 I may dislike not using return but please consider at the very 
 least using ; instead of , for the last element do(x, y ; z). 
 Just something to hint that the last one is special.
Not a bad idea, actually. I feel like the semicolon should be allowed, but not enforced. If another two or three people also like this idea I'll go ahead and implement it, and adjust the DIP.
Sep 03 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, September 03, 2016 14:42:34 Cauterite via Digitalmars-d wrote:
 On Saturday, 3 September 2016 at 14:25:49 UTC, rikki cattermole

 wrote:
 I propose a slight change:
 do(x, y, return z)
Hmm, I suppose I should mention one other motivation behind this DIP: I really like to avoid using the 'return' keyword inside expressions, because I find it visually confusing - hear me out here - When you're reading a function and trying to understand its control flow, one of the main elements you're searching for is all the places the function can return from. If the code has a lot of anonymous functions with return statements this can really slow down the process as you have to more carefully inspect every return to see if it's a 'real' return or inside an anonymous function. Also, in case it wasn't obvious, the do() syntax was inspired by Clojure: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
So, instead of having the return statement which everyone knows to look for and is easy to grep for, you want to add a way to return _without_ a return statement? That's just _begging_ for trouble IMHO. There's no question that it will be confusing, and unless you have a ton of anonymous functions or nested functions returning within a function (which most D code doesn't), then I don't see how there's any question that it's worse. And since most D code doesn't have a lot of nested constructs with a function which have return statements, it seems to me that we're really just making it harder for most programmers to find all of the return statements within a function. - Jonathan M Davis
Sep 03 2016
next sibling parent Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 16:03:39 UTC, Jonathan M Davis 
wrote:
 So, instead of having the return statement which everyone knows 
 to look for and is easy to grep for, you want to add a way to 
 return _without_ a return statement?
I think you've misunderstood. Even with DoExpressions, the only way to return from a function without a return statement is in a lambda '=>' function.
Sep 03 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/3/16 12:03 PM, Jonathan M Davis via Digitalmars-d wrote:
 On Saturday, September 03, 2016 14:42:34 Cauterite via Digitalmars-d wrote:
 On Saturday, 3 September 2016 at 14:25:49 UTC, rikki cattermole

 wrote:
 I propose a slight change:
 do(x, y, return z)
Hmm, I suppose I should mention one other motivation behind this DIP: I really like to avoid using the 'return' keyword inside expressions, because I find it visually confusing - hear me out here - When you're reading a function and trying to understand its control flow, one of the main elements you're searching for is all the places the function can return from. If the code has a lot of anonymous functions with return statements this can really slow down the process as you have to more carefully inspect every return to see if it's a 'real' return or inside an anonymous function. Also, in case it wasn't obvious, the do() syntax was inspired by Clojure: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
So, instead of having the return statement which everyone knows to look for and is easy to grep for, you want to add a way to return _without_ a return statement?
No, the amendment is to show that z is the "return" of the do expression. It doesn't return from the function the do expression is in. I also think that a) we shouldn't have a requirement, or support for, return inside the expression -- return is not actually an expression, it's a statement. This would be very confusing. b) I like the idea of the semicolon to show that the last expression is different. I'm not sure I agree with the general principal of the DIP though. I've never liked comma expressions, and this seems like a waste of syntax. Won't tuples suffice here when they take over the syntax? e.g. (x, y, z)[$-1] -Steve
Sep 06 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06.09.2016 16:12, Steven Schveighoffer wrote:
 I'm not sure I agree with the general principal of the DIP though. I've
 never liked comma expressions, and this seems like a waste of syntax.
 Won't tuples suffice here when they take over the syntax? e.g. (x, y,
 z)[$-1]
(Does not work if x, y or z is of type 'void'.)
Sep 06 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/6/16 10:17 AM, Timon Gehr wrote:
 On 06.09.2016 16:12, Steven Schveighoffer wrote:
 I'm not sure I agree with the general principal of the DIP though. I've
 never liked comma expressions, and this seems like a waste of syntax.
 Won't tuples suffice here when they take over the syntax? e.g. (x, y,
 z)[$-1]
(Does not work if x, y or z is of type 'void'.)
Let's first stipulate that z cannot be void here, as the context is you want to evaluate to the result of some expression. But why wouldn't a tuple of type (void, void, T) be valid? It could also auto-reduce to just (T). -Steve
Sep 06 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06.09.2016 17:23, Steven Schveighoffer wrote:
 On 9/6/16 10:17 AM, Timon Gehr wrote:
 On 06.09.2016 16:12, Steven Schveighoffer wrote:
 I'm not sure I agree with the general principal of the DIP though. I've
 never liked comma expressions, and this seems like a waste of syntax.
 Won't tuples suffice here when they take over the syntax? e.g. (x, y,
 z)[$-1]
(Does not work if x, y or z is of type 'void'.)
Let's first stipulate that z cannot be void here, as the context is you want to evaluate to the result of some expression. But why wouldn't a tuple of type (void, void, T) be valid?
Because 'void' is special. (Language design error imported from C.) struct S{ void x; // does not work. } There can be no field (or variables) of type 'void'. (void,void,T) has two fields of type 'void'. Just fixing the limitations is also not really possible, as e.g. void* and void[] exploit that 'void' is special and have a non-compositional meaning.
 It could also auto-reduce to just (T).

 -Steve
That would fix the limitation, but it is also quite surprising behaviour.
Sep 06 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/6/16 1:01 PM, Timon Gehr wrote:
 On 06.09.2016 17:23, Steven Schveighoffer wrote:
 On 9/6/16 10:17 AM, Timon Gehr wrote:
 On 06.09.2016 16:12, Steven Schveighoffer wrote:
 I'm not sure I agree with the general principal of the DIP though. I've
 never liked comma expressions, and this seems like a waste of syntax.
 Won't tuples suffice here when they take over the syntax? e.g. (x, y,
 z)[$-1]
(Does not work if x, y or z is of type 'void'.)
Let's first stipulate that z cannot be void here, as the context is you want to evaluate to the result of some expression. But why wouldn't a tuple of type (void, void, T) be valid?
Because 'void' is special. (Language design error imported from C.)
builtin tuples can be special too... -Steve
Sep 06 2016
prev sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
 There can be no field (or variables) of type 'void'. 
 (void,void,T) has two fields of type 'void'.

 Just fixing the limitations is also not really possible, as 
 e.g. void* and void[] exploit that 'void' is special and have a 
 non-compositional meaning.
Out of interest: What's the matter here? Can't `void` just get a size of 1 byte? Or is there a problem with `void*` being a super type of any pointer type? The same wouldn't need to apply to `void` itself, AFAICS.
Sep 07 2016
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07.09.2016 14:19, Marc Schütz wrote:
 On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
 There can be no field (or variables) of type 'void'. (void,void,T) has
 two fields of type 'void'.

 Just fixing the limitations is also not really possible, as e.g. void*
 and void[] exploit that 'void' is special and have a non-compositional
 meaning.
Out of interest: What's the matter here?
Well, maybe you are right and this should be done as far as possible, but the type should not have been overloaded in the first place. AFAIU it's called void because the C designers intended that there should be no value of type void. But a function that returns a value of a type that does not have any values cannot return at all. Instead it should have precisely one value, which means that values of the type carry no information. Making 'void' an unit type to the extent possible is probably better than what we have now, but void* and void[] would become even more weird than they are now.
 Can't `void` just get a size of
 1 byte?
void.sizeof is 1, but void.init is invalid.
 Or is there a problem with `void*` being a super type of any
 pointer type?
It occupies syntax that should have a different meaning. void[] x = [123456789]; void y = x[0]; void z = x[1]; assert(y==z); // ??? void foo(){} auto a=[foo()]; void v=a[0];
 The same wouldn't need to apply to `void` itself, AFAICS.
Well, no, but there is no non-breaking way to get rid of the non-compositional meaning of void* and void[]. I.e. you can "fix" void up to the point where you want to e.g. allow building an array of voids.
Sep 07 2016
prev sibling next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 3 September 2016 at 14:20:28 UTC, Dicebot wrote:
 DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

 Abstract
 --------

 A DoExpression do(x,y,z) is exactly equivalent to a 
 CommaExpression
 (x,y,z), but doesn't emit a deprecation warning.

 ==============================================

 First community DIP has just landed the review queue. Please 
 express your opinion and suggestions - it will all be taken 
 into consideration when the formal review time comes.
The same can be already achieved using a function literal. Introducing an expression for this seems overkill.
Sep 03 2016
next sibling parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 14:26:30 UTC, Stefan Koch wrote:
 Introducing an expression for this seems overkill.
The same could be said for the '=>' lambda syntax. Doesn't do anything that {return x;} can't do.
Sep 03 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 4:49 PM, Cauterite wrote:
 On Saturday, 3 September 2016 at 14:26:30 UTC, Stefan Koch wrote:
 Introducing an expression for this seems overkill.
The same could be said for the '=>' lambda syntax. Doesn't do anything that {return x;} can't do.
Lambdas are a matter of frequency. -- Andrei
Sep 03 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 4:26 PM, Stefan Koch wrote:
 The same can be already achieved using a function literal.
Even better! -- Andrei
Sep 03 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 4:20 PM, Dicebot wrote:
 DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

 Abstract
 --------

 A DoExpression do(x,y,z) is exactly equivalent to a CommaExpression
 (x,y,z), but doesn't emit a deprecation warning.

 ==============================================

 First community DIP has just landed the review queue. Please express
 your opinion and suggestions - it will all be taken into consideration
 when the formal review time comes.
What's wrong with: auto seq(T...)(auto ref T vals) { return vals[$ - 1]; } ? We need to fix order of evaluation of function arguments anyway. Andrei
Sep 03 2016
next sibling parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 15:28:36 UTC, Andrei 
Alexandrescu wrote:
 What's wrong with:

 auto seq(T...)(auto ref T vals) { return vals[$ - 1]; }
Well there's nothing *wrong* with that, but I really think that 'do' is the perfect word for this purpose, and the fact that it's already a keyword is real convenient. For just 10 lines in parse.d we get this great syntax, no code breakage, no need to copy-paste a little template around.
Sep 03 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 6:19 PM, Cauterite wrote:
 On Saturday, 3 September 2016 at 15:28:36 UTC, Andrei Alexandrescu wrote:
 What's wrong with:

 auto seq(T...)(auto ref T vals) { return vals[$ - 1]; }
Well there's nothing *wrong* with that, but I really think that 'do' is the perfect word for this purpose, and the fact that it's already a keyword is real convenient. For just 10 lines in parse.d we get this great syntax, no code breakage, no need to copy-paste a little template around.
This is a terrible argument. It has "why not" all over it. -- Andrei
Sep 03 2016
parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 16:28:15 UTC, Andrei 
Alexandrescu wrote:
 This is a terrible argument. It has "why not" all over it. -- 
 Andrei
Sorry, it's my first time proposing a language feature.
Sep 03 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 6:39 PM, Cauterite wrote:
 On Saturday, 3 September 2016 at 16:28:15 UTC, Andrei Alexandrescu wrote:
 This is a terrible argument. It has "why not" all over it. -- Andrei
Sorry, it's my first time proposing a language feature.
My DConf 2016 talk has a few considerations on what makes a good proposal. We consider it an antipattern to list reasons for why not adding a feature. It's like on a date - if nothing went wrong, that doesn't mean anything went right :o). -- Andrei
Sep 03 2016
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03.09.2016 17:28, Andrei Alexandrescu wrote:
 What's wrong with:

 auto seq(T...)(auto ref T vals) { return vals[$ - 1]; }
- The name (I'd expect that function to return vals). - Does not work if one or more arguments is of type 'void'. (Arguably that's just a language misdesign.)
Sep 03 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, September 03, 2016 17:20:28 Dicebot via Digitalmars-d wrote:
 DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

 Abstract
 --------

 A DoExpression do(x,y,z) is exactly equivalent to a CommaExpression
 (x,y,z), but doesn't emit a deprecation warning.

 ==============================================

 First community DIP has just landed the review queue. Please express
 your opinion and suggestions - it will all be taken into consideration
 when the formal review time comes.
Occasionally, the comma expression is useful, but the reality of the matter is that almost no one uses it, and from what I've seen, it seems to be the case that just about only the only folks who read it correctly are the ones who use it frequently. Granted, giving it a new keyword will make it harder to use that functionality by accident, but it's still going to be confusing to many folks. I think that we're much better off just killing it off. It's not getting killed off just because there are folks who want to use commas for tuples. It's being killed off because so many folks think that it's a bad idea. - Jonathan M Davis
Sep 03 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/16 6:10 PM, Jonathan M Davis via Digitalmars-d wrote:
 I think that we're much better off just killing it off.
We're better off with what we have right now: you can use comma, just don't take the last value. Absent a smoking gun (and one very smokey and stinky at that), I don't see the purpose of DIP1001. I suggest we just retire it. Andrei
Sep 03 2016
prev sibling parent Cauterite <cauterite gmail.com> writes:
On Saturday, 3 September 2016 at 16:10:16 UTC, Jonathan M Davis 
wrote:
 .. and from what I've seen, it seems to be the case that just 
 about only the only folks who read it correctly are the ones 
 who use it frequently ..
You know what else is easy to misread? { x; y; return z; }(); Because until you reach the () at the end you have no idea whether this is supposed to be an anonymous function to be called elsewhere or a series of statements to be executed right now. Sure, the comma expression isn't used very often, but when I do need to use it I don't want to have to put garbage syntax like that in my code. When you're reading code and you see `do(` you know straight away what's going on.
Sep 03 2016