Generality creep

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sat Mar 30 18:32:31 UTC 2019


On Thursday, March 28, 2019 3:13:17 PM MDT ag0aep6g via Digitalmars-d wrote:
> On 28.03.19 21:05, Andrei Alexandrescu wrote:
> > We must excise the cancerous tissue.
>
> We can cut out the bad parts, but leave the useful core of RefRange
> intact, can't we?
>
> The useful core is: a range that wraps a pointer to another range in
> order to achieve reference semantics. Often, a pointer to a range is
> already a range, but not always. E.g., `int[]*` is not a range.

The problem is that reference semantics and forward ranges do not go well
together at all. As things stand, range-based code is supposed to work with
forward ranges that are reference types, and we have save to try and deal
with the fact that some ranges are value types, some are reference types,
and some are pseudo-reference types, but it really doesn't work very well.
And algorithms that require save fundamentally need to copy the range at
some point, pretty much destroying the usefulness of something like
RefRange.

Basic input ranges are fundamentally reference types or pseudo-reference
types, because if they could have value semantics, then they could be
forward ranges. Forward ranges fundamentally have to be copyable with value
semantics to even work properly. We've just got this messed up situation
where we're using save to do the copy instead of postblit or copy
constuctors, because we're trying to handle types that aren't value types as
if they were.

RefRange is trying to force reference semantics, which then fundamentally
doesn't fit with forward ranges. It sort of half fits right now, because of
save, but as with forward ranges that are reference types, it causes
problems, and code frequently isn't going to work with it without extra
work.

As such, I really don't think that RefRange makes sense fundamentally. It
_can_ work in corner cases, and years ago, I had a piece of code where it
was really useful, which is why I wrote it. But it was a mistake. It's
trying to fight against how forward ranges work, and while it might
occasionally be useful, in general, it's going to cause problems.

And if we actually go forward with requiring that basic input ranges have
reference semantics and that forward ranges have value semantics like Andrei
is proposing, then RefRange _really_ doesn't work.

- Jonathan M Davis





More information about the Digitalmars-d mailing list