A Discussion of Tuple Syntax

[Kenji Hara]

2013/8/20 Dicebot <public at dicebot.lv>

> What we have here are two completely different _built-in_ tuple types. "T"
> is pure template arguments list and is pretty much equal TypeTuple!(int,
> int). But what is "args"? It uses the very same built-in tuple syntax but
> it is much closer to std.typecons.Tuple in its behavior (actually, latter
> is implemented in terms of it as I was pointed out) - it is an entity that
> provides abstraction of top of group of run-time values. It does not have
> any binary structure on its own (built on top of existing values) but
> observable semantic are very "run-time'ish".
>

"args" is a built-in tuple of two function parameter variables. In binary
level, args[0] and args[1] could be bounded to completely individual
storage. (Even if args[1] is on stack, args[0] may be on register)
On the other hand, std.typecons.Tuple is a struct. Its second field has the
memory address which follows of the first field.

What bothers me is the question "can we clean this up and bring those two
> worlds together, even at cost of minor breakage?". I am not speaking about
> literals here or unpacking or whatever. I am speaking about re-defining
> semantics so that struct-based Tuple and built-in syntax sugar in form of
> run-time expression tuple both get merged into one built-in construct which
> can be used in wider variety of places.


> At least right now I can't find any technical objections why expression
> tuple can't use std.typecons.Tuple ABI when returned from function but
> still be automatically expanded when passed into functions. Kenji, what is
> your your opinion about complexity to implement something like that in DMD?
>

Automatically packing/unpacking would need hidden runtime cost.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130821/064cbe8a/attachment.html>