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
