March 24, 2014
On Monday, 24 March 2014 at 14:49:09 UTC, Regan Heath wrote:
> On Mon, 24 Mar 2014 11:35:38 -0000, monarch_dodra <monarchdodra@gmail.com> wrote:
>
>> On Monday, 24 March 2014 at 10:57:45 UTC, Regan Heath wrote:
>>> On Sun, 23 Mar 2014 20:56:25 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>>
>>> Would it have any effect on:
>>>
>>> int *p, q;
>>
>> That's not a comma operator. So no.
>
> That's my Q answered :)
>
>> BTW, I'd *STRONGLY* urge you to write that as:
>> int* p, q;
>>
>> since in D, both "p" and "q" are of type "int*", unlike in C.
>
> I am well aware :p

I thought so :) but this being a forum and all, "bad code" should always be tagged as such.
March 24, 2014
On Monday, 24 March 2014 at 12:44:22 UTC, bearophile wrote:
> 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

Do you know what Rust does in the case of 1-tuples?
March 24, 2014
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>
> Andrei

I like comma operator and use often in my code, it's a very nice syntactic construct for mini-statements.

if(len<=optlen)opti=i, optj=j, optlen=len;
March 24, 2014
On 3/24/14, 5:18 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Monday, 24 March 2014 at 04:00:14 UTC, Andrei Alexandrescu wrote:
>> On 3/23/14, 8:30 PM, bearophile wrote:
>>> How is this more limited change affecting possible future syntax usage
>>> of commas for tuples? :-)
>>
>> The change has an eye to that. Disallowing the use of the return value
>> offers us the future possibility of redefining it. -- Andrei
>
> This is nice, although I guess it will make parsing harder. It probably
> means that the distinction between "," as operator and tuple element
> separator will be context-dependent.

No, parsing stays the same. You can think of comma returning a tuple. But for now we're forcing that tuple to never be used, so as to not change code semantics.

Andrei
March 24, 2014
On 3/24/14, 5:25 AM, 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.

How about

tuple(1,2)    two-element tuple
tuple(1)      one-element tuple
(1)           simple expression
tuple()       empty tuple

Oh, wait...


Andrei
March 24, 2014
On 3/24/14, 5:35 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> 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.

Breaking druntime and phobos in multiple places counts as very frequent. -- Andrei
March 24, 2014
On 3/24/14, 5:44 AM, bearophile wrote:
> 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}

WTF???

tuple()
tuple(a)
tuple(a, b)
tuple(a, b, c)


Andrei

March 24, 2014
Andrei Alexandrescu:

>> 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}
>
> WTF???
>
> tuple()
> tuple(a)
> tuple(a, b)
> tuple(a, b, c)
>
>
> Andrei

So you are saying you want to support a syntax like this?

tuple(a, b, c) = myFunc();

Bye,
bearophile
March 24, 2014
> So you are saying you want to support a syntax like this?
>
> tuple(a, b, c) = myFunc();

And:

foreach (tuple(a, b, c); myTuples) {}

void foo(in auto tuple(a, b, c)) {}

Bye,
bearophile
March 24, 2014
On Monday, 24 March 2014 at 16:57:09 UTC, bearophile wrote:
> So you are saying you want to support a syntax like this?
>
> tuple(a, b, c) = myFunc();
>
> Bye,
> bearophile

This actually almost works:

auto foo()
{
	return tuple(1, 2, 3);
}

void main()
{
	int a, b, c;
	
	tuple(a, b, c) = foo();
	writeln(a, b, c); // 000
	
	TypeTuple!(a, b, c) = foo();
	writeln(a, b, c); // 123
}