compile-time opIndex

[H. S. Teoh via Digitalmars-d]

On Thu, Jan 01, 2015 at 01:42:45PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 12/31/14 6:05 PM, Dicebot wrote:
> >On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via
> >Digitalmars-d wrote:
> >>people demanded Tuple support.
> >
> >Was it bearophile? :P I can't stop feeling that it is simply not
> >recognized enough how bad D tuples are if such request arises. I'd
> >personally try to avoid those in almost all cases where it is
> >practically feasible.
> 
> Right now, ranges properly work with phobos ONLY if they are tuples
> (specifically std.typecons.Tuple). The idea is that eventually there
> will be more support for builtin tuples, and at that point, the
> requirement will shift to the builtin tuple.
> 
> The "fear" is that if you have .key and .value support, and somehow
> this is impossible to support and also support builtin tuples (I
> highly doubt this), then we wouldn't be able to use builtin tuples as
> a return type for aa.byPair.front. Thereby making AA's incompatible
> with phobos ranges.
> 
> IMO, having SOMETHING in AA.byPair is better than nothing. I really am
> not worried at all about range tuple support, and I think it will be
> doable when "real tuples" arrive -- support will be additive.
> 
> And I'm also with you that if you don't have .key .value support, this
> isn't worth having.
[...]

The way I see it, this is an acceptable compromise:

1) Have .byKeyValue in druntime, which returns a struct with .key and
.value;

2) Have .byPair in Phobos (via UFCS), which wraps around .byKeyValue and
returns a Tuple of .key and .value.


T

-- 
Question authority. Don't ask why, just do it.