front stability

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 30, 2016 at 07:23:24PM +0000, default0 via Digitalmars-d wrote:
> On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer wrote:
[...]
[...]
> > Unfortunately, for the likes of forward ranges, copying mainly
> > always does the same thing as .save does. So you have tons and tons
> > of code that doesn't properly use .save. Such is the way things are,
> > and I'm not sure it will ever get better :(
> > 
> > -Steve
> 
> Can we have ranges that disallow using them like rangeCache = range;
> without sacrificing usability in other cases? Going forward having
> ranges that simply do not compile when used that way would probably
> make lots of people actually honor .save and allow the compiler to
> point out buggy code (even if, in the end, .save really comes down to
> a no-op for many ranges).

Andrei has mentioned that, in retrospect, we should have defined forward
ranges such that copying the range object *is* saving. (Though it is
unclear to me what is to be done with by-reference ranges like range
classes, since you'd still need a separate method to be able to copy the
class object. Unless you wrap them in a struct that calls the copy
method in its postblit.)

That aside, though, I'm not sure how you'd enforce not copying a range.
The range API is defined by constraints rather than a language-level
Concept, so the actual range object could be any arbitrary type. It
doesn't seem to make sense that the assignment operator should suddenly
be prohibited just because it happens to have members named .front,
.empty, .popFront.  Besides, outside of generic code, what if the
user-defined range is actually such that assignment does the Right
Thing(tm)?  The cases that we want to prohibit are restricted only to
generic code, since code that already "knows" the concrete type
shouldn't be arbitrarily restricted like this.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser