Summary: obj[n] not allowed for user-defined tuples
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

This is an annoying issue that makes tuples one order of magnitude less
appealing than they might be.

Currently, there is no literal to define type tuples but the TypeTuple
supplants it:

template TypeTuple(T...) { alias T TypeTuple; }


alias TypeTuple!(int, float) T;

you can use its type members with T[0] and T[1]. Furthermore, creating a value
of type T also works and allows you to access the members with t[0] and t[1].

There are some problems with tuple values, e.g. they can't be returned from

T fun()
   T result;
   result[0] = 1;
   result[1] = 1.1;
   return result; // can't return a tuple

So then I created std.typecons.Tuple which has a field of type TypeTuple and
various ways to get at it. The problem with that is that I can't reproduce the
most desirable for getting fields: var[index]. What can be done is:

(1) var.field[0], var.field[1]

This is bad because these can't be functions; field must be exposed directly.
Therefore, writing tuple proxies that use the same syntax is impossible. That
turns out to be a major problem.


This is ugly and requires one to press shift a million times. The alternative!0 works, but doesn't quite cut the mustard.

(3) var._0, var._1

This is ugly too, and also needs to be complemented with one of (1) or (2)
because it doesn't allow iteration with numbers. Never grew on me, and I've
been using it for quite a while.

So we'd want to allow var[0], var[1] etc. There are several possibilities of
doing so, the simplest being CTFE:

struct Tuple(T...)
    private T field;
    ref T[i] opIndex(size_t i) { return field[i]; }

If you pass a compile-time index, the function should work. Right now it does
only confuse the compiler :o).


Reply via email to