More tricky range semantics

[H. S. Teoh via Digitalmars-d]

On Thu, Jan 15, 2015 at 03:25:38PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/15/15 12:53 PM, H. S. Teoh via Digitalmars-d wrote:
> >This issue is already latent in almost*all*  Phobos algorithms.  We
> >only haven't discovered it yet because most people just use arrays
> >for ranges. But all it takes is for somebody to start using
> >std.range.inputRangeObject (and there are cases where this is
> >necessary), and this problem will surface.
> 
> There's a distinction here. Input non-forward ranges can be considered
> "reference" because popFront()ing any copy is tantamount to
> popFront()int any other copy. -- Andrei

I hope you realize that inputRangeObject, in spite of its name, does
forward methods of the higher ranges (.save, .popBack, etc.), right?

Besides, conflating reference types with non-forward input ranges will
cripple ranges built not only from class objects, but from *any* type
(even structs) that exhibit reference semantics. One particular poignant
example is your proposed groupBy replacement, which uses RefCounted,
which has reference semantics. :-) We wouldn't want to be breaking that
now, would we?

(On the flip side, perhaps now you might finally see some justification
for my hesitation about implementing groupBy with reference
semantics...)


T

-- 
Let's eat some disquits while we format the biskettes.