2013/8/20 Dicebot <pub...@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