[Issue 2628] obj[n] not allowed for user-defined tuples

2015-06-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2628

Andrei Alexandrescu  changed:

   What|Removed |Added

Version|unspecified |D2

--


[Issue 2628] obj[n] not allowed for user-defined tuples

2011-01-08 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2628


Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #5 from Andrei Alexandrescu  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: ---


[Issue 2628] obj[n] not allowed for user-defined tuples

2009-01-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2628





--- Comment #4 from kamm-removet...@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.


-- 



[Issue 2628] obj[n] not allowed for user-defined tuples

2009-01-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2628





--- Comment #3 from and...@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.


-- 



[Issue 2628] obj[n] not allowed for user-defined tuples

2009-01-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2628





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


-- 



[Issue 2628] obj[n] not allowed for user-defined tuples

2009-01-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2628





--- Comment #1 from samu...@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.


--