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