May 13, 2016
On Thursday, 12 May 2016 at 02:51:33 UTC, Lionello Lunesu wrote:
> I'm trying to think of a case where changing a single value into a tuple with 2 (or more) values would silently change the behavior, but I can't think of any. Seems to me it would always cause an error, iff the result of the comma operator gets used.

int x,y;
auto f() {return (x=4,y);}
...
auto z = f();
static if (!is(typeof(z) == int)
  voteForTrump();

;-)

In practice, this is more plausible with function overloading - i.e. z.overload() calling a different function. If the comma operator returns void, the `auto z` line and f().overload() both fail.
May 21, 2016
On 13/5/2016 20:44, Nick Treleaven wrote:
> On Thursday, 12 May 2016 at 02:51:33 UTC, Lionello Lunesu wrote:
>> I'm trying to think of a case where changing a single value into a
>> tuple with 2 (or more) values would silently change the behavior, but
>> I can't think of any. Seems to me it would always cause an error, iff
>> the result of the comma operator gets used.
>
> int x,y;
> auto f() {return (x=4,y);}
> ...
> auto z = f();
> static if (!is(typeof(z) == int)
>    voteForTrump();
>
> ;-)
>
> In practice, this is more plausible with function overloading - i.e.
> z.overload() calling a different function. If the comma operator returns
> void, the `auto z` line and f().overload() both fail.

Good point. Thanks.
June 10, 2016
On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote:
> Before we get lost in the discussions, let's act on this by disallowing taking the result of the comma operator. Yes there is potential breakage (via typeof as Timon noted) but it's likely to be minimal. Once we have that in place we have more options. Thx! -- Andrei

Just a quick update on that topic: using the return of a comma operator now yield a deprecation message (using DMD ~master). This will be part of 2.072.0.
Thanks everyone for your feedback !
June 10, 2016
On 6/10/16 1:02 PM, Mathias Lang wrote:
> On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote:
>> Before we get lost in the discussions, let's act on this by
>> disallowing taking the result of the comma operator. Yes there is
>> potential breakage (via typeof as Timon noted) but it's likely to be
>> minimal. Once we have that in place we have more options. Thx! -- Andrei
>
> Just a quick update on that topic: using the return of a comma operator
> now yield a deprecation message (using DMD ~master). This will be part
> of 2.072.0.
> Thanks everyone for your feedback !

That's terrific. Thank you!! -- Andrei
June 10, 2016
On Fri, Jun 10, 2016 at 05:11:59PM +0000, Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/10/16 1:02 PM, Mathias Lang wrote:
> > On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote:
> > > Before we get lost in the discussions, let's act on this by disallowing taking the result of the comma operator. Yes there is potential breakage (via typeof as Timon noted) but it's likely to be minimal. Once we have that in place we have more options. Thx! -- Andrei
> > 
> > Just a quick update on that topic: using the return of a comma operator now yield a deprecation message (using DMD ~master). This will be part of 2.072.0.  Thanks everyone for your feedback !
> 
> That's terrific. Thank you!! -- Andrei

Hooray! One small step in the right direction of killing off the comma operator for good.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
5 days ago
On Tuesday, 10 May 2016 at 12:49:28 UTC, Steven Schveighoffer wrote:
> BTW, has anyone proposed a replacement like this?
>
> auto ref comma(T...)(auto ref T t) if(T.length > 1)
> {
>    return t[$-1];
> }

That won't work with void expressions.

Here's a version which does:

https://github.com/CyberShadow/ae/commit/1405e9deff60d33952e52600bc1d1fcbf3511084
Next ›   Last »
1 2 3 4 5 6 7