Tuple literal syntax

[retard]

Thu, 07 Oct 2010 17:22:08 +0200, Simen kjaeraas wrote:

> retard <re at tard.com.invalid> wrote:
> 
>>>> 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).
> 
> What? You really think structs/tuples are implemented like
> Variant[string]?
> 
> foo.bar => *(&foo + bar.offsetof), where offsetof is known at
> compiletime. It doesn't get faster than that.

There are several conflicting concepts at stake here. I guess the 
nominative typing is quite clear -- the type name fully dictates the 
physical and logical form of the data.

But structural typing can be implemented in several ways. I use the name 
'record' for tuples with field names. This notation doesn't necessarily 
define any physical order of fields in the memory. When you bring an 
aggregate from the tuple world to the struct world, you have to lock down 
some physical layout for the data.

If you don't have first class tuple constructors and define them with a 
template, that's unfortunately not structural typing. The D's structs 
might use the copying semantics from structural typing, but it's a weird 
hybrid type, actually. Just like the tuples aren't real tuples. Field 
names break the definition. Type tuples break it, too.