Wider tuple design discussion

Don nospam at nospam.com
Tue Aug 2 09:47:11 PDT 2011


Michel Fortin wrote:
> On 2011-08-02 13:15:52 +0000, bearophile <bearophileHUGS at lycos.com> said:
> 
>> A tuple isn't an object, it's more like a record, it's almost like a 
>> more handy POD. So tuples are data structures that you use with code 
>> (functions) that they don't contain.
> 
> Actually, that's up to debate in my opinion. Andrei's Tuple in phobos is 
> a struct, so it's a POD like you say. Walter's tuples in the language 
> are just collections of variables.

In fact they're collections of symbols, which can be types, variables, 
or values...


> 
> A language tuple does not have an address in itself, it essentially has 
> one address per field. This actually makes tuple packing/unpacking very 
> efficient across function calls (because there's no real 
> packing/unpacking taking place), but it makes it impossible to take the 
> address of a tuple.
> 
> We need a way to make those two concepts work together, I think that's 
> the hard part.
> 
> 
>> Tuples do have some disadvantages. Their fields often are anonymous, 
>> this goes against the typical well defined style of D/Java/Ada 
>> programs, where you know the name of what you are using. So tuples are 
>> better if you use them locally, or if they have only few items. Long 
>> tuples become hard to use because you risk forgetting what each field 
>> is, so the most common tuples have between 2 and 5 items.
> 
> Named tuple elements in a language tuple will be implemented when/if 
> someone implement named arguments, something I might do eventually.



More information about the Digitalmars-d mailing list