forward ranges must offer a save() function

[Rainer Deyke]

bearophile wrote:
> Rainer Deyke:
>> Allowing ranges to have either value or reference semantics is a 
>> disaster,
> 
> At the moment you can put the methods that define a range into a
> struct, or inside an class (just like you can put opApply inside a
> struct or class). What do you suggest? To allow such methods inside
> classes only? Uhm.

Ranges are defined as a concept.  A concept is not just a list of
methods, but a specification for the semantics of the type.  I suggest
that the "range" concept unambiguously defines the semantics of the
assignment operations.  My preference is to use value semantics.  Move
semantics would also work.  Both would require a 'struct' type (which
can be a thin wrapper around a 'class' type).

(My real preference is to remove the value/reference type schism
entirely, but that's not what I'm suggesting here.)


-- 
Rainer Deyke - rainerd at eldwood.com