On Thu, 27 Mar 2014 11:45:50 -0000, Kagamin <spam@here.lot> wrote:

> On Thursday, 27 March 2014 at 10:39:58 UTC, Regan Heath wrote:
>> On Wed, 26 Mar 2014 22:02:44 -0000, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>>> On 03/26/2014 05:19 PM, H. S. Teoh wrote:
>>>> 	int x = 1, 5;	// hands up, how many understand what this does?
>>>
>>> Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.
>>
>> Spectacularly proving his point :p
>
> Did he want to kill the declaration statement too?

No.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 27 Mar 2014 00:35:38 -0400, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 27 March 2014 at 02:08:50 UTC, Steven Schveighoffer wrote:
>> On Wed, 26 Mar 2014 17:32:00 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>>> On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>>>> This is valid in both C and C++:
>>>>
>>>>   i, j = 0, 1;
>>>>
>>>> It is equivalent to the following:
>>>>
>>>>   i;
>>>>   j = 0;
>>>>   1;
...
>> '=' has precedence over ','.
>>
>
> I think you get operator priority wrong and it will be (i), (j = 0), (1). I added extra () to show how operator priority works.

I think that's what I said, no?

-Steve

On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu
wrote:
> 2. The semantics is the same unless warnings are enabled with "-w"
>
> 3. In "-w" mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void.
>
> 4. Later on the warning will be promoted to a deprecation followed by removal from the language.

Semantic changes based on warning or deprecation flags are a bad
idea, because it breaks code unless warnings are disabled.
The cycle should go warning => deprecation => semantic
change/removal, each step taking 6 month.

On Tuesday, 25 March 2014 at 19:09:01 UTC, Andrei Alexandrescu wrote:
>> You mentioned in the other thread
>> that we are looking at 5 years or more before the comma operator can be
>> used in tuple expressions. Is that timeline still accurate with these
>> proposed changes?
>
> I'm afraid so. But that's the case regardless.

Sounds like a terrible idea as tuples are such an important tool in a modern programming language.
It also seems unnecessary because there are many syntax alternatives. In fact a syntax decision would be the missing ingredient to get http://wiki.dlang.org/DIP32 rolling.

On Friday, 28 March 2014 at 02:21:11 UTC, Martin Nowak wrote:
> Sounds like a terrible idea as tuples are such an important tool in a modern programming language.
> It also seems unnecessary because there are many syntax alternatives. In fact a syntax decision would be the missing ingredient to get http://wiki.dlang.org/DIP32 rolling.

The problem with tuples is not syntax, but semantics: DIP32 should specify, when automatic unpacking happens and when doesn't, that's a very sloppy feature, so it should be specified better. Other corner cases I can think about: is one-element tuple equivalent to that one element, is array literal a tuple, is string literal a tuple, how to infer packed and unpacked tuples, how to remember all these subtle features?

Kagamin:

> The problem with tuples is not syntax, but semantics: DIP32 should specify, when automatic unpacking happens and when doesn't, that's a very sloppy feature, so it should be specified better.

OK. (But from the last posts on the topic Andrei seems unfit to design D tuples).


> Other corner cases I can think about: is one-element tuple equivalent to that one element,

Nope, this is sloppy.


> is array literal a tuple,

Nope. But some explicit conversions are useful.


> is string literal a tuple,

The same as arrays.


> how to infer packed and unpacked tuples,

I don't understand.


> how to remember all these subtle features?

Really, a well designed tuple type is a very simple datatype. So a well designed tuple has a natural syntax and a very simple semantics with no corner cases, that is easy to remember. If it gets hard to remember, it should be redesigned or simplified.

Bye,
bearophile

On 3/28/14, 2:15 AM, bearophile wrote:
> Kagamin:
>
>> The problem with tuples is not syntax, but semantics: DIP32 should
>> specify, when automatic unpacking happens and when doesn't, that's a
>> very sloppy feature, so it should be specified better.
>
> OK. (But from the last posts on the topic Andrei seems unfit to design D
> tuples).

Where did that one come from? Oh boy.

Andrei

Andrei Alexandrescu:

> On 3/28/14, 2:15 AM, bearophile wrote:
>> OK. (But from the last posts on the topic Andrei seems unfit to design D
>> tuples).
>
> Where did that one come from? Oh boy.

It came mostly from this answer of yours:

> That would be a different function but same syntax. In fact
> for safety I favor myFunc().scatter(a, b, c)

A syntax like that misses the points of the discussions we have had why a better tuple syntax is useful.

Bye,
bearophile