www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No mass assignments for tuples

reply bearophile <bearophileHUGS lycos.com> writes:
Kenji Hara has created a very nice pull request that implements a first step of
good tuple unpacking syntax for D, that is waiting for review and eventual
improvements.

Walter has said (here: http://d.puremagic.com/issues/show_bug.cgi?id=6365#c26 )
that "We should step back and figure out what we want to do with tuples in the
much more general case", this means he wants D tuples to be well thought-out to
avoid future troubles, and I agree on this. So here here are my thoughts about
one thing (probably the only one) that I don't like about Kenji Hara proposal.

Currently this D code compiles and works, and I think it's bad/broken/ugly
(http://d.puremagic.com/issues/show_bug.cgi?id=6367 ):


import std.typetuple;
void main() {
    TypeTuple!(int, int) f = 10;
    assert(f[0] == 10);
    assert(f[1] == 10);
}


I think that this broken/bad behaviour is currently present in the proposed
tuple unpacking syntax too:
https://github.com/9rnsr/dmd/commit/0d05ce48ffe4e74f2d1ef04e1e6692a59d9ddb44

46 +    auto (i, j) = 10;
47 +    assert(i == 10);
48 +    assert(j == 10);


This goes against any implementation of tuples I have seen in all other
languages, it's generally not useful, and I think it's going to cause troubles
too. So I suggest to not carry this broken/bad behaviour of typetuples to
tuples too.

And I question this design for typetuples too. Is it a good design? I don't
think so, I'd like to see it removed/disallowed for typetuples too (for
uniformity with tuples too).

And if you want to answer something about static arrays:
int[2] a;
a = 5;

I question that syntax too, elsewhere I have asked that to become a syntax
error, and accept only a slice assignment syntax, more uniform with all other
vector operations:
int[2] a;
a[] = 5;

Bye,
bearophile
Dec 10 2011
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-12-2011 15:46, bearophile wrote:

 Kenji Hara has created a very nice pull request that implements a first step
of good tuple unpacking syntax for D, that is waiting for review and eventual
improvements.

 Walter has said (here: http://d.puremagic.com/issues/show_bug.cgi?id=6365#c26
) that "We should step back and figure out what we want to do with tuples in
the much more general case", this means he wants D tuples to be well
thought-out to avoid future troubles, and I agree on this. So here here are my
thoughts about one thing (probably the only one) that I don't like about Kenji
Hara proposal.

 Currently this D code compiles and works, and I think it's bad/broken/ugly
(http://d.puremagic.com/issues/show_bug.cgi?id=6367 ):


 import std.typetuple;
 void main() {
      TypeTuple!(int, int) f = 10;
      assert(f[0] == 10);
      assert(f[1] == 10);
 }


 I think that this broken/bad behaviour is currently present in the proposed
tuple unpacking syntax too:
 https://github.com/9rnsr/dmd/commit/0d05ce48ffe4e74f2d1ef04e1e6692a59d9ddb44

 46 +    auto (i, j) = 10;
 47 +    assert(i == 10);
 48 +    assert(j == 10);


 This goes against any implementation of tuples I have seen in all other
languages, it's generally not useful, and I think it's going to cause troubles
too. So I suggest to not carry this broken/bad behaviour of typetuples to
tuples too.

 And I question this design for typetuples too. Is it a good design? I don't
think so, I'd like to see it removed/disallowed for typetuples too (for
uniformity with tuples too).

 And if you want to answer something about static arrays:
 int[2] a;
 a = 5;

 I question that syntax too, elsewhere I have asked that to become a syntax
error, and accept only a slice assignment syntax, more uniform with all other
vector operations:
 int[2] a;
 a[] = 5;

 Bye,
 bearophile


Such assignments do seem rather error-prone.

- Alex
Dec 11 2011
prev sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Sat, 10 Dec 2011 15:46:15 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:


 46 +    auto (i, j) = 10;
 47 +    assert(i == 10);
 48 +    assert(j == 10);


Yeah, this is not good. Also, didn't we settle for (auto i, j)?
Dec 11 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/12/2011 12:23 AM, Simen Kjærås wrote:

 On Sat, 10 Dec 2011 15:46:15 +0100, bearophile
 <bearophileHUGS lycos.com> wrote:


 46 + auto (i, j) = 10;
 47 + assert(i == 10);
 48 + assert(j == 10);


 Yeah, this is not good. Also, didn't we settle for (auto i, j)?


AFAIK the patch implements both, and I think that is the way it should be.
Dec 11 2011
parent =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Mon, 12 Dec 2011 03:31:29 +0100, Timon Gehr <timon.gehr gmx.ch> wrote=
:


 On 12/12/2011 12:23 AM, Simen Kj=C3=A6r=C3=A5s wrote:

 On Sat, 10 Dec 2011 15:46:15 +0100, bearophile
 <bearophileHUGS lycos.com> wrote:


 46 + auto (i, j) =3D 10;
 47 + assert(i =3D=3D 10);
 48 + assert(j =3D=3D 10);


 Yeah, this is not good. Also, didn't we settle for (auto i, j)?


 AFAIK the patch implements both, and I think that is the way it should=


  =


 be.


As do I, but I think (auto i, j) is the most important of the two.
Dec 11 2011