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.
