called copy constructor in foreach with ref on Range

[H. S. Teoh]

On Mon, Jun 22, 2020 at 08:53:22PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
[...]
> Exactly. It's because of issues like this that generic, range-based
> functions need to be tested with a variety of range types - including
> reference types. Without that, bugs are routinely missed.
[...]
> If we do actually rework the range API as has occasionally been
> discussed, it would be _really_ nice if we could more thoroughly
> restrict the copying semantics of ranges so that some of these
> problems go away, but without such a redesign, we're stuck with such
> problems.

Redesign or not, I think the new range API should be much more specific
in specifying exactly what behaviours ranges ought to have.  The current
API is under-specified, with two of the main problem points that I can
remember being:

1) Transient-ness: is the value return by .front guaranteed to remain
   valid, or does .popFront invalidate it?  This is not specified in the
   current spec, and we have ranges in Phobos of either type (e.g., iota
   and .byLine), with a lot of code just blindly assuming non-transience
   only to discover that things break down when handed a .byLine
   instance.

2) The exact semantics of copying (assigning) a range. What parts of a
   range's state is/isn't preserved when you assign a range to a local
   variable, for example?  What happens if you pass a range to a
   function and then continue to operate on the original?  All of this
   must be specified precisely in the range API so that we don't have
   one range acting one way and another range acting another way,
   thereby compromising the semantics of generic code.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond