• d-bugmail puremagic.com Jan 27 2009
• d-bugmail puremagic.com Jan 28 2009
• d-bugmail puremagic.com Jan 28 2009
• d-bugmail puremagic.com Jan 28 2009
• d-bugmail puremagic.com Jan 28 2009
• d-bugmail puremagic.com Jan 08 2011

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628

           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
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: andrei metalanguage.com


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; }

Given:

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
functions:

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.

(2) var.at!(0), var.at!(1)

This is ugly and requires one to press shift a million times. The alternative
var.at!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).


-- 

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628





------- Comment #1 from samukha voliacable.com  2009-01-28 02:25 -------
 struct Tuple(T...)
 {
    private T field;
    ref T[i] opIndex(size_t i) { return field[i]; }
 }


That won't work as the return type of the function would depend on the function
argument. At least until the requirement for CTFE functions to be evaluatable
both at compile time and at run time is abolished.


-- 

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628





------- Comment #2 from andrei metalanguage.com  2009-01-28 08:09 -------
*** Bug 2629 has been marked as a duplicate of this bug. ***


-- 

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628





------- Comment #3 from andrei metalanguage.com  2009-01-28 08:35 -------
(In reply to comment #1)
 struct Tuple(T...)
 {
    private T field;
    ref T[i] opIndex(size_t i) { return field[i]; }
 }


 That won't work as the return type of the function would depend on the function
 argument. At least until the requirement for CTFE functions to be evaluatable
 both at compile time and at run time is abolished.


Indeed. I also discussed that with Walter last night and allowing it is
possible but would have ripples through the rest of the compiler.

The feature can be allowed; the problem is that there's no obvious way to allow
it without making it a hack that people will need to learn.


-- 

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628





------- Comment #4 from kamm-removethis incasoftware.de  2009-01-28 10:31
-------
What about allowing a template signature for opIndex

T opIndex(size_t i)();

that is only valid if there's no classical opIndex defined. For types with such
an opIndex, rewrite instance[j] as instance.opIndex!(j)() for compile-time
constant indices. opSlice could get the same treatment.

While it'd still be a special case, it'd be one that could just be added to the
list of operator overloads without confusing people unduly.


-- 

d-bugmail puremagic.com writes:

http://d.puremagic.com/issues/show_bug.cgi?id=2628


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #5 from Andrei Alexandrescu <andrei metalanguage.com> 2011-01-08
15:55:08 PST ---
Fixed a while ago.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------