What is the stance on partial initializers when declaring multiplevariables of the same type?

[kenji hara]

In current D, following code is valid.

import std.typetuple : seq = TypeTuple;
void main()
{
  int x, y;
  seq!(x, y) = seq!(1, 2);  // assign
  assert(x == 1);
  assert(y == 2);
}

Kenji Hara

2011/7/22 Jonathan M Davis <jmdavisProg at gmx.com>:
> On 2011-07-21 16:54, Andrei Alexandrescu wrote:
>> On 7/21/11 6:44 PM, Simen Kjaeraas wrote:
>> > On Thu, 21 Jul 2011 23:40:08 +0200, bearophile
>> >
>> > <bearophileHUGS at lycos.com> wrote:
>> >> Nick Sabalausky:
>> >>> Crazy, nutty, wacky idea...
>> >>>
>> >>> float (a, b, c) = 0.0;
>> >>
>> >> I'd like some syntax sugar for tuples in D (especially for their
>> >> unpacking), that syntax goes against one of the most natural ways to
>> >> define tuples. So it's not a good idea.
>> >
>> > It is highly unlikely that D will ever adopt that syntax for tuples,
>> > due to the previously much-discussed comma operator (which, while
>> > uncommon, is useful at times). I believe the syntax that came out on
>> > top in earlier discussions was the upended hamburger bun, or banana
>> > syntax:
>> >
>> > (| float f, string s |) foo = (| 1.2, "Eh, whut?" |);
>>
>> Here's a crazy idea:
>>
>> auto foo = tuple(1.2, "Eh, whut?");
>
> Is this particular case, a built-in syntax buys you nothing, as you
> demonstrate. I think that the case that Bearophile is always looking for is
> something like this:
>
> int i;
> float f;
>
> (i, f) = tuple(5, 2.2);
>
> though that's more useful when the function is something fancier than tuple
> which just so happens to return a tuple (as opposed to being specifically
> designed just for creating them). How useful that really is ultimately, I
> don't know, but it certainly adds something which you can't do without changes
> to the language itself. Aside from assigning the pieces of a returned tuple to
> existing local variables like that, I'm not aware of any real gain from adding
> tuples directly to the language. Our template solution works quite well
> overall. And whether assigning to existing local variables like above actually
> makes adding tuples to the language itself worth it is certainly up for
> debate. But I believe that that's the use case that Bearophile is particularly
> interested in.
>
> - Jonathan M Davis
>