Using non-copyable types

[H. S. Teoh]

On Thu, May 23, 2019 at 06:33:04PM +0000, Yuxuan Shui via Digitalmars-d wrote:
> On Thursday, 23 May 2019 at 18:18:02 UTC, H. S. Teoh wrote:
> > On Thu, May 23, 2019 at 06:05:41PM +0000, Yuxuan Shui via Digitalmars-d
> > wrote:
> > > [...]
> > 
> > Wrap them in a reference. I.e., instead of passing the range itself,
> > pass a pointer to the range. Or use a suitable wrapper struct with
> > reference semantics.  Thanks to D unifying member invocation via
> > object and via pointer to object, this should be mostly transparent
> > to Phobos algorithms. This gets around the complications with
> > postblits / copy ctors and Phobos assumptions about copyability.
> > 
> > 	NonCopyableRange r = ...;
> > 	auto rp = &r;
> > 	result = rp.map!(...).filter!(...).joiner; // etc.
[...]
> What about Tuple?

Probably have to create a new Tuple that references the uncopyable
object in the original.


> These are probably not the best examples, I just sense there is a
> general lack of consideration of non-copyable types in phobos.

Certainly, because non-copyable types were added to the language after
the fact.  Like so many additions that people clamor for, they add many
complications and unexpected interactions with existing language
features, and also break assumptions Phobos was originally predicated
upon, thereby introducing subtle bugs and/or corner cases that didn't
exist when the code was written.

Basically, Phobos was written assuming that ranges are mutable and
assignable, and that .init exists and is valid. When one or more of
these is false, you'll get a lot of unexpected behaviours.  The .init
stuff may have been fixed by now, but I wouldn't be surprised if there
are still places where this assumption is still being made. The
assignable part may have been mostly fixed, but there are still a lot of
places where this is assumed.

This is probably part of the reason W&A have very high standards when it
comes to adding new features. Most of the time the people clamoring for
the new feature fail to realize the full implications of adding it to
the language. Breaking Phobos assumptions is one of the things people
rarely think about, and it's particularly pernicious because the
breakage is silent and nobody is aware until long after the new feature
has been merged and stabilized, and it's too late to back out.


T

-- 
INTEL = Only half of "intelligence".