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