Tuple literal syntax

[retard]

Thu, 07 Oct 2010 09:46:59 -0500, Andrei Alexandrescu wrote:

> On 10/7/10 5:39 CDT, retard wrote:
>> Thu, 07 Oct 2010 03:20:23 -0500, Andrei Alexandrescu wrote:
>>
>>> Sorry for being Debbie Downer in this thread, but I'm not seeing a lot
>>> of progress here. This is nothing but a syntax cutesy that helps
>>> Tuple!(A, B) and tuple(a, b) and leaves all other issues related to
>>> tuples unresolved (I'm actually afraid that it exacerbates them).
>>>
>>> One good thing about Tuple is that it allows names of fields, so
>>> functions can return tuples with conveniently named fields, e.g.
>>> Tuple!(bool, "found", size_t, "position") etc. without having to
>>> define little structs everywhere and fostering simple, clear code on
>>> the caller side.
>>
>> Why do tuple fields need a name?
> 
> They don't always need, but oftentimes names are better than numeric
> constants.

If some compile time voodoo isn't used, the names have an effect on the 
performance (runtime lookups).

> 
>> Isn't this a new ad-hoc way to introduce structural typing in D?
> 
> Well what is the old ad-hoc way? Anyhow, tuples are a prime candidate
> for structural typing. Currently Tuple does not support it.

I have nothing against the structural typing of tuples, per se. I meant 
structural typing in the sense that Scala implements it -- a set of name-
value pairs constructs a new type. It seems to require runtime 
dictionaries in their implementation.

> 
>> I often start with tuples, but if it turns out that the value is used
>> in many places, it will be eventually replaced with a struct (e.g.
>> coordinates in a gui / gamedev) for better type safety.
> 
> I don't see
> 
> struct Coord
> {
>      int x, y, z;
> }
> 
> one iota typesafer than
> 
> alias Tuple!(int, "x", int, "y", int, "z") Coord;

I meant the naming of the aggregate vs not naming it. Passing around n-
tuples without any name associated for the concept allows mixing n-tuples 
if the internal type structure matches. Sometimes I want to distinguish 
between the uses. Clearly some coordinate in the game world shouldn't 
automatically be applicable in the GUI context:

struct GameCoord {
  int x,y,z;
}

struct GUICoord {
  int x,y,z;
}

// void drawOval(GUICoord); // fun prototype

GameCoord a;
drawOval(a); // bang

This might lead to bugs if the compiler silently accepts a wrong 
aggregate.

>> Even with structs the need for field names is very rare.
> 
> I don't know how to define a struct without naming its fields in C, C++,
> C#, or D. If I could, I'd seldom want to use magic indexes instead of
> descriptive names.

I didn't know what the template creates. I had an impression that it 
creates an array of strings for some runtime purposes, like:

foreach(value; tuple) {
  writefln("%s is %s", value.name, value);
}

So I was just refering to those runtime string literals. Maybe I confused 
this with some enum related template.

 
>> The real
>> need for tuples is in very special cases where the syntax needs to be
>> light.
> 
> auto r = fun(42);
> writeln(r.foo, ": ", r.bar);
> 
> On the client side the syntax is very light. The definition of the
> function would need to specify the type name:
> 
> Tuple!(int, "foo", string, "bar") fun(int) {
>      ...
> }

We have an issue with terminology here. To me that isn't a *tuple*, it's 
a record! A tuple would let you choose the variable names on the client 
side:

auto (foo, bar) = fun(42);

writeln(foo, ": ", bar);