How is chunkBy supposed to behave on copy

[H. S. Teoh]

On Thu, Mar 19, 2020 at 05:15:51PM +0000, Dukc via Digitalmars-d wrote:
> On Thursday, 19 March 2020 at 16:01:39 UTC, H. S. Teoh wrote:
> > 
> > The problem is, you *cannot* give any guarantees about copy
> > behaviour, because it depends on the behaviour of the incoming
> > range. For example, if you pass the output of .byChunk to another
> > range algorithm, that second algorithm cannot guarantee copy
> > behaviour anymore.
> > 
> > In fact, all you have to do is to wrap a forward range in an
> > InputRangeObject (let's say you need to alternate between two
> > different range types (but with compatible elements) at runtime,
> > then you'll need to do this), and now you have a forward range with
> > by-reference semantics that requires the use of .save in order to
> > retain its current position.
> 
> The documentation would say that the copy behaviour of the range is
> the same as the source range has. A guarantee to depend on the source
> range is still a guarantee, and definitely better than the present
> situation.

A guarantee about copy behaviour potentially binds the Phobos
maintainers to the specifics of the current implementation of the
algorithm.  I'm not sure that's what we want, since it may limit future
improvements.

The thing about the range API is that it's like a contract between user
code and Phobos; the way you use it should be according to the contract,
anything not stated by the contract should not be relied upon even if
currently it happens to work.  That's the principle of encapsulation.
Behaviours that arise from the specifics of how something is currently
implemented are implementation details that shouldn't leak into the
calling code, including assumptions about copy behaviour.  Arguably,
relying on a specific copy behaviour is an instance of leaky
abstraction, since outside code shouldn't know nor depend upon Phobos
internal implementation details.  Part of the power of encapsulation is
to leave certain non-essential things unspecified, so that implementors
can have greater freedom in how they implement the API.  Something that
isn't directly related to the particular function (e.g., the primary
function of byChunk) shouldn't be a part of the API, IMO, it should be
left unspecified with the understanding that relying on the behaviour of
something unspecified runs the risk of future breakage.  The specific
behaviour ought to be inside the "black box" of encapsulation, not
relied upon by user code, much less specified in library docs.


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.