I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated.


Thanks,

Andrei

On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated.
>
>
> Thanks,
>
> Andrei


Yay! vote += infinity

Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I don't see what's confusing about that. I also am opposed to the idea to limit tuples to 2 or more elements. On the contrary, I root for the clean semantics of having a proper unit type represented as () instead of the horrible C semantics of the 'void' type. Just make void an alias to () for backwards compatibility.
Also, why the need to special case the for loop? the increment part can be a regular tuple since the for loop doesn't
for (int i, j; cond; i++, j++) {}

On 9/23/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

About the (,) problem, what about using (void)? It's longer to type
but it might be easier to humanly decode than trying to count lone
commas.

((1, ), (,))
((1, void), void, (void))

On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
> On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
>> I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>>
>> Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated.
>>
>>
>> Thanks,
>>
>> Andrei
>
>

Yay! vote += infinity

Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't assign
the value of the expression.
for (int i, j; cond; i++, j++) {}

I'd suggest looking at functional implementations such as ML or Haskel for more inspiration.

On Sunday, 23 September 2012 at 21:00:39 UTC, foobar wrote:
> On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
>> On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
>>> I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
>>>
>>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>>>
>>> Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>>
>
> Yay! vote += infinity
>
> Regarding specifics,
> I'd argue that (int) should be a perfectly valid construct. I
> don't see what's confusing about that. I also am opposed to the
> idea to limit tuples to 2 or more elements. On the contrary, I
> root for the clean semantics of having a proper unit type
> represented as () instead of the horrible C semantics of the
> 'void' type. Just make void an alias to () for backwards
> compatibility.
> Also, why the need to special case the for loop? the increment
> part can be a regular tuple since the for loop doesn't assign
> the value of the expression.
> for (int i, j; cond; i++, j++) {}
>
> I'd suggest looking at functional implementations such as ML or Haskel for more inspiration.

urg.. .Sorry for the double posting..

Also, I want to add that type declarations should be changed from statements to expressions so that we could do:
auto tup = (3, "hello");
(int num, string s) = tup; // num == 3, s == "hello"

Le 23/09/2012 22:40, Andrei Alexandrescu a écrit :
> I discussed this with Walter, and we concluded that we could deprecate
> the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> Unfortunately, I started much cockier than I ended. The analysis in
> there fails to construct a case even half strong that deprecating the
> comma operator could significantly help tuples. Well it essentially
> concludes that tuples are mostly fine as they are, and attempts to
> embellish them syntactically are marred with unexpected problems.
> Nevertheless, I sure have missed aspects all over, so contributions are
> appreciated.
>
>
> Thanks,
>
> Andrei

This is a problem I think about for a while, and coding for SDC + studying how it is done in other languages has enlightened me on some points.

I all for deprecating the comma operator. You have my full support on that point. As well as you have it for the « for » construct update.

However, I'm not sure about everything you propose to implement tuples. I could discuss idea about 1 element tuples, or other tricky cases that deserve discussion (and I'm sure they will).

But first, let me digress. D is already a really good language. One of its main flaw is the lack of 3rd party tools. The way new feature are implemented is a real problem for 3rd party tool developers. In other terms, the arm done by adding new feature is greater than any benefit new feature can bring us.

Additionally, we have some open mess that need to be closed. Think about the -property madness, the holes in const/immutable transitivity, or other half buggy features.

I consider that , operator should be deprecated then removed ASAP. It will limit the amount of code possibly broken in the future.

But let's not introduce any new feature before at least introducing a versioning scheme that allow user to keep the version without the feature.

I'm not for removing the comma operator, but it occurs to me we could do it in the library:

auto commaOperatorReplacement(T...)(T t) {
   return t[$-1];
}

There might be some edge case where that wouldn't work, but I think it works in most cases.

On 09/23/2012 10:58 PM, foobar wrote:
> On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
>> I discussed this with Walter, and we concluded that we could deprecate
>> the comma operator if it helps tuples. So I started with this:
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>>
>> Unfortunately, I started much cockier than I ended. The analysis in
>> there fails to construct a case even half strong that deprecating the
>> comma operator could significantly help tuples. Well it essentially
>> concludes that tuples are mostly fine as they are, and attempts to
>> embellish them syntactically are marred with unexpected problems.
>> Nevertheless, I sure have missed aspects all over, so contributions
>> are appreciated.
>>
>>
>> Thanks,
>>
>> Andrei
>
>
> Yay! vote += infinity
>
> Regarding specifics,
> I'd argue that (int) should be a perfectly valid construct.

If so, it should be the same as int.

> I don't see what's confusing about that.

Those are currently both valid and give the same result:

int.max
(int).max

Anyway, the tuple type should resemble the tuple expression
syntactically.

> I also am opposed to the idea to limit
> tuples to 2 or more elements. On the contrary, I root for the clean
> semantics of having a proper unit type represented as () instead of the
> horrible C semantics of the 'void' type. Just make void an alias to ()
> for backwards compatibility.

You mean, alias () to 'void' for backwards compatibility. How would
that give 'clean semantics'? It's just syntax. Or is it about void
supporting 'expand'? I don't think that makes sense.

void foo(){}

void main(){
    void[] x = new int[42];
    foo(x[0].expand); // whut?
}


> Also, why the need to special case the for loop? the increment part can
> be a regular tuple since the for loop doesn't assign the value of the
> expression. for (int i, j; cond; i++, j++) {}

I assume Andrei intends the enclosing parens to be mandatory.

> I'd suggest looking at functional implementations such as ML or Haskel[l] for more inspiration.

They just do the two most obvious things. (well, Haskell has to answer
some questions related to the evaluation model that are irrelevant for
D.)

Neither one has a syntactic construct for building a single element tuple.

> Also, I want to add that type declarations should be changed from statements to expressions so that we could do:
> auto tup = (3, "hello");
> (int num, string s) = tup; // num == 3, s == "hello"

I'd support the addition of declaration expressions (mainly for using
them in conjuncts of if conditions), but this is not necessary to
enable what you show above.

Ok, here's a crazy idea:

Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those...

Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes >1 vs <=1. Well, *mechanically* yes, but consider this:

*Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*.

Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.)

So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are.

That means (at least I think it means) that things like () or (1) or
((1)) require no way to disambiguate between tuple and expression,
because either way they're the same thing (or at least freely
convertible).

Le 23/09/2012 23:52, Nick Sabalausky a écrit :
> Ok, here's a crazy idea:
>
> Do the reasons for explicit tuple-expansion necessarily apply to
> zero- and one-element tuples? I'm not so sure. Suppose we allowed
> implicit expansion on those...
>
> Now I know what you're thinking: That would be an ugly inconsistency
> between tuples of sizes>1 vs<=1. Well, *mechanically* yes, but
> consider this:
>
> *Logically* speaking, is there really any difference between a
> one-element tuple and an ordinary single value? I don't think so, and
> here's why: What is a tuple, logically speaking? Multiple values being
> handled as if they were a single value. So what's a one-element tuple?
> *One* value being handled as if it were one value - which is *is*.
>
> Similarly, a zero-element tuple is logically equivalent to void (or the
> one value a void can have: the value void, a concept which has been
> argued in the past that might be useful for D, particularly in
> metaprogramming). (I admit this is a little weaker than my argument
> for one-element tuples.)
>
> So perhaps zero- and one-element tuples should be implicitly
> convertible back and forth with void and ordinary non-tuple values,
> respectively (polysemous values?), because that's what they essentially
> are.
>

My reflection on the subject for the past month lead me to the same conclusion.

> That means (at least I think it means) that things like () or (1) or
> ((1)) require no way to disambiguate between tuple and expression,
> because either way they're the same thing (or at least freely
> convertible).
>

Exactly.