On Monday, 24 March 2014 at 00:59:00 UTC, Andrei Alexandrescu wrote:
> On 3/23/14, 5:41 PM, Meta wrote:
>> On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:
>>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>>
>>> Andrei
>>
>> You mentioned on the Github PR that this broke some Phobos (and
>> Druntime?) code. What was the extent of the breakage? If it's small, I'd
>> say give it a year-long deprecation period and then be done with it
>> forever.
>
> The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import.
>
> Top factors:
>
> 0. Any silent breakages or changes in semantics? 100000000x
>

None in this case.

> 1. How frequent is the breakage? Is most code going to still work? 100x

Very infrequent, judging by other peoples' repsonses here, and the fact that there were only a handful of places in all of druntime and Phobos.

>
> 2. How much does fixing the breakage improve code? Was the breaking code incorrect for the most part? 100x

As I wrote elsewhere, my main motivation for the PR was enabling a possible future tuple literal syntax, multiple return values, unpacking assignment and the like. The gains were therefore not so much in detecting wrong code, although apparently there is some from time to time:
https://d.puremagic.com/issues/show_bug.cgi?id=2659

On Monday, 24 March 2014 at 12:32:30 UTC, Steven Schveighoffer wrote:
> On Sun, 23 Mar 2014 22:31:25 -0400, Andrei Alexandrescu In fact, if this was the case, I would use the comma operator more. How many times I have to change:
>
> if(cond)
>    exp;
>
> into
>
> if(cond)
> {
>    exp;
>    exp2;
> }
>
> Would be nice to just do:
>
> if(cond)
>    exp, exp2;
>
> -Steve

//----
if(cond)
    {exp; exp2;}
//----

?

For what it's worth, it's what we do in our production code. And it's safer. A copy paste that produces:
//----
if(cond)
    exp; exp2;
//----

Can happen so fast, and is virtually un-catcheable unless it actually breaks something.

On Monday, 24 March 2014 at 12:25:58 UTC, w0rp wrote:
> Please kill the comma operator with fire. Is is just bad.
>
> On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote:
>> Or, if you really want to distinguish them, this would work:
>>
>> (1,2)    two-element tuple
>> (1,)     one-element tuple
>> (1)      simple expression
>> (,)      empty tuple
>
> I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple. It may be less of an issue in a static language, but it will still be an issue. I don't have an alternative syntax to propose.

I'm not familiar with Python. What is the difference between a one-element tuple and an expression? Are Python tuples just arrays?

On Mon, 24 Mar 2014 08:38:14 -0400, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Monday, 24 March 2014 at 12:32:30 UTC, Steven Schveighoffer wrote:
>> On Sun, 23 Mar 2014 22:31:25 -0400, Andrei Alexandrescu In fact, if this was the case, I would use the comma operator more. How many times I have to change:
>>
>> if(cond)
>>    exp;
>>
>> into
>>
>> if(cond)
>> {
>>    exp;
>>    exp2;
>> }
>>
>> Would be nice to just do:
>>
>> if(cond)
>>    exp, exp2;
>>
>> -Steve
>
> //----
> if(cond)
>      {exp; exp2;}
> //----
>
> ?
>
> For what it's worth, it's what we do in our production code. And it's safer. A copy paste that produces:
> //----
> if(cond)
>      exp; exp2;
> //----
>
> Can happen so fast, and is virtually un-catcheable unless it actually breaks something.

I have an allergic reaction to braces on the same lines :) Only place I ever use them is when the whole function can fit on the same line.

-Steve

w0rp:

> I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple.

I agree, 1-tuples in Python are tricky. Compare it with the clear Python list literal syntax:

[]        => 0-length list
[1]       => 1-length list
[1, 2]    => 2-length list
[1, 2, 3] => 2-length list

Unfortunately ASCII offers a limited choice of delimiters :-)


> I don't have an alternative syntax to propose.

Look at some of the syntaxes here:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

One of the syntaxes:

@{}
@{a}
@{a, b}
@{a, b, c}

Bye,
bearophile

On Monday, 24 March 2014 at 12:31:16 UTC, Russel Winder wrote:
> On Mon, 2014-03-24 at 12:20 +0000, Marc =?UTF-8?B?U2Now7x0eiI=?=
> @puremagic.com wrote:
> […]
>> Or, if you really want to distinguish them, this would work:
>> 
>> (1,2)    two-element tuple
>> (1,)     one-element tuple
>> (1)      simple expression
>> (,)      empty tuple
>
> The Python solution is:
>
> (1, 2)  two-element tuple
> (1,)  one-element tuple
> (1)  simple expression
> ()  empty tuple

I'm used to this now, but initially it stuck out like a sore thumb for a language that's supposed to be noob friendly. It gets the job done I suppose.

On Monday, 24 March 2014 at 12:10:40 UTC, Marc Schütz wrote:
> On Monday, 24 March 2014 at 01:28:02 UTC, Kenji Hara wrote:
>> I'm partially against to it.
>>
>> 1. I think removing comma operator does not have useful effect for tuple
>> syntax discussion. For example:
>>
>>   1a. If you want to use parenthesis syntax (...) for tuple, we should
>> resolve one-element tuple ambiguity first.
>>         (exp)   // one-element tuple, or just an expression ?
>>      And,  removing comma operator does not resolve this issue.
>
> I believe this is a non-issue. From a language-users POV, there should be no difference between a one-element tuple and an expression, thus there's no need to distinguish the two. (The actual implementation in the compiler may of course treat them differently.)

On second thought, this would probably lead to problems in generic code, if we want to iterate over a tuple whose length we do not know, and which happens to have one element only. So there definitely needs to be a distinction between tuples and non-tuples.

But as this is about syntax only, the question is: Do we even need a dedicated syntax for one-element (and zero-element) tuples? When those are needed, they can easily be created using std.typecons.tuple(). The syntactic sugar is only really useful when we have multiple values, be it for returning or for assignment.

On Monday, 24 March 2014 at 12:39:53 UTC, Marc Schütz wrote:
> On Monday, 24 March 2014 at 12:25:58 UTC, w0rp wrote:
>> Please kill the comma operator with fire. Is is just bad.
>>
>> On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote:
>>> Or, if you really want to distinguish them, this would work:
>>>
>>> (1,2)    two-element tuple
>>> (1,)     one-element tuple
>>> (1)      simple expression
>>> (,)      empty tuple
>>
>> I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple. It may be less of an issue in a static language, but it will still be an issue. I don't have an alternative syntax to propose.
>
> I'm not familiar with Python. What is the difference between a one-element tuple and an expression? Are Python tuples just arrays?

Consider the following.

>>> (1, 2)

(1, 2)

>>> (1)

1

>>> (1 * (3 * 4,))

(-1, )

>>> (1 * (3 - 4,) * 2)

(-1, -1)

>>> foo = lambda : 3

>>> (
...     foo()
... )

3

>>> (
...     foo(),
... )

(3, )

I see this kind of confusion happen often, and the convenient syntax becomes a burden.

On Mon, 2014-03-24 at 12:39 +0000, Marc =?UTF-8?B?U2Now7x0eiI=?=
@puremagic.com wrote:
[…]
> I'm not familiar with Python. What is the difference between a one-element tuple and an expression? Are Python tuples just arrays?

Tuples are sequences, expressions are scalars: a tuple is effectively an immutable list.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 24 March 2014 at 12:43:22 UTC, Steven Schveighoffer wrote:
> I have an allergic reaction to braces on the same lines :) Only place I ever use them is when the whole function can fit on the same line.
>
> -Steve

I get that "allergic reaction" :)

But it does have its advantages in terms of robustness (accidental ";"), and scaling. For example, there are cases where "," can't be used:

Type myType;
if(cond)
    {int dummy = 5; initialize(myType, dummy);}

As a general rule, I feel that "{}" is ugly, but that once they are there, no-one is going to break my code.