rotate left an array

[H. S. Teoh]

On Mon, Oct 03, 2022 at 05:38:25PM -0700, Ali Çehreli via Digitalmars-d-learn wrote:
[...]
> Good catch but I think what we want is a copy of the front element, at
> least for InputRanges (.save does not work for File.byLine :/).

One of the things we need to settle in Phobos v2 is what to do with
transient ranges like File.byLine (i.e., ranges whose .front value is
invalidated by .popFront).  When you don't need to access each line
after calling .popFront, .byLine's current implementation reduces
allocations and decreases GC pressure.  However, when you do need to
save it, it produces counterintuitive results, like here.


> What is the generic way of copying an element? I wonder whether we
> have to use isSomeString to take care of all element types.
[...]

This was discussed many years ago.  There is no generic way to copy an
element, because there is no language-wide .clone method that enforces
the right semantics for every type.  You cannot simply deep-copy
something, as might be a tempting solution at first glance, because you
cannot tell, for an arbitary type, whether a reference member is meant
to be an owning reference (the referent needs to be cloned) or a
non-owning reference (the referent should not be cloned).  Both are
valid use cases, and there is no way to distinguish between them without
contextual knowledge of the type.

For example, if your range is generating, say, a tree of objects each
time .popFront is called, then you probably want to deep-copy the object
tree when you're saving the element.  However, if the range is iterating
over, say, some nodes in a preexisting graph, then you probably *don't*
want to be duplicating graph nodes when you save the value of .front,
because in this case .front merely references these nodes, it doesn't
own them.  Without application-specific knowledge, you can't tell which
of these cases you're dealing with.


T

-- 
Customer support: the art of getting your clients to pay for your own incompetence.