On 10/7/10 13:56 CDT, retard wrote:
Thu, 07 Oct 2010 13:48:31 -0500, Andrei Alexandrescu wrote:

On 10/7/10 13:44 CDT, retard wrote:
Thu, 07 Oct 2010 19:12:45 +0200, Simen kjaeraas wrote:

retard<[email protected]>   wrote:

If you don't have first class tuple constructors and define them with
a template, that's unfortunately not structural typing.

Might I inquire as to why?

I see these "tuples" defined with a template merely as structs in
disguise. They don't cover all the cases where built-in first class
tuples can be used.

Could you please take the time to put together a list of requirements?
That would be great for either making Tuple better or for improving the
language.

Sure, but I can't really promise to have to capacity to think about every
possible case when we are discussing D. There are so many complex
features! I think a more or less complete list can already be constructed
from all past discussions here. The tuple issues come up every now and
then.

Yah, and it might be the case that we're too close to the matter sometimes. A simple out-of-the-box list should help. I'd start it like this:

- must contain an unlimited number of values, including non-distinct types etc.

- should be first-class values (e.g. array of tuples or returning tuples should require no tricks)

- should support controlled expansion, i.e. I decide when the tuple "explodes" whereas everywhere else it's a sheer value. Consider:

void foo(T)(T obj);
void foo(T, U)(T obj1, U obj2);
foo(tuple(1, 2.2));

Which function should be called? Any way we go, we should be able to call the first overload (because tuples are first-class values!!! the circle closes!!!) but we should also be able to call the second overload if we so want. (By sheer luck, Tuple currently supports that beautifully: foo(tuple(1, 2.2)) calls the first overload and foo(tuple(1, 2.2).expand) calls the second one.)

- should support coherent conversion and perhaps subtyping, taking projections (slices), cross-product (concatenation)

- should be easy to use, terse, and self-explanatory

- should support simple "gathering" (assigning from various values) and "scattering" (assigning to various values)

What else?

FWIW, the library provided solution with syntactical support doesn't
sound so bad now that I think about it. We just need to know, what we are
trying to solve here. The bigger problems come up when overloading the
same system with mixed value/type/alias tuples.

I, too, have learned to appreciate library solutions more because I realized a few things. One, I really don't need to explain what this is:

auto x = tuple(1, 2.3);

or this

Tuple!(int, double) y;

or this

auto z = tuple("hello");

I mean it's as there as it gets. But I will need some explaining and some head scratching to figure this:

auto z = ("hello",);

and this:

auto t = ();

and this:

(int, double) foo(bool(int, double) bar);

Library tuples rule.


Andrei

Reply via email to