"the last change" for ranges
sandford at jhu.edu
Wed May 20 10:42:25 PDT 2009
On Wed, 20 May 2009 13:04:42 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>> On Wed, May 20, 2009 at 9:19 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> I'm thinking a better design is to require any range that's forward or
>>> better to define a function save(). Ranges that don't implement it are
>>> ranges; those that do, will guarantee a brand new range is returned
>>> save(). So then adjacentFind would look like this:
>>> R adjacentFind(R)(R r)
>>> if (r,empty) return r;
>>> R last = r.save;
>>> for (; !r.empty && last.front != r.front; last.popFront, r.popFront)
>>> return r;
>>> Obviously, when you pass a range that doesn't support save,
>>> will not compile, which is what we want.
>> The only other alternative that comes to mind would be forcing input
>> ranges to hide their copy constructor, or whatever the D equivalent
>> is, making R last = r; fail. But that would make input ranges very
>> difficult to use.
> Exactly. I thought of that design, and it was difficult to even pass a
> range to a function.
>> So, of those two options at least, requiring a .save sounds like the
>> better choice.
>> The down side is you will get no error if you write the code the first
>> way, without a .save. I see this as turning into tip #5 in
>> "Effective D" -- "Know when to use .save" It would be nice if that
>> potential mistake could be eliminated somehow. You could perhaps
>> require input ranges to implement transfer semantics, and have them
>> implement a .clone for cases when you really do want to make an
>> aliasing copy.
> Good point. I don't have a solution for that. Giving ranges move
> semantics would probably make for another Effective D tip (or perhaps
> more... move semantics are pretty brutal).
> Another partial solution is to define a different interface for input
> ranges, one that combines front() and popFront(). Something like
> popNext. That way, people who use only the primitives empty() and
> popNext() know they are using a forward range and with hope they'll
> remember they can't really save copies of it and expect them to
> "remember" where they are in the input.
Bicycle shed: Well, since output ranges use 'put', how about 'get' for
More information about the Digitalmars-d