The new, new phobos sneak preview

Daniel Keep daniel.keep.lists at gmail.com
Mon Apr 13 19:51:39 PDT 2009



Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> Actually, I've been thinking and I realised that in 95% of cases, you
>> can assume a range is resumable if it has no references.
> 
> Well I'm not so sure. How about a range around an integral file handle
> or socket?

Most of the time, I'd expect people to be accessing those via the
standard library.  And that wraps them in objects.  :)

>> If it has no
>> references, the only way the range can be non-resumable is if the
>> advance member uses the range's state as an argument to some global
>> method.  An example might be a Range that statically accesses Stdout
>> instead of taking it as an argument.
>>
>> It's a real shame the range interface doesn't support this:
>>
>>> struct R
>>> {
>>>     ...
>>>     pure R advance();
>>> }
>>
>> If it did, we could prove a range was resumable if advance was pure and
>> R has no mutable or const references.
> 
> Hmmmm... well, pure changes "this". We'd need to say that it only
> changes state owned by "this", but we have no notion of "almost pure".

Hence why I made R a return value.  If you have a member function that's
pure in every way EXCEPT that it changes "this", you can rewrite it like so:

> R range = getRange();
> range = range.advance;

Ta-da, advance can be pure since the changes are pushed out via the
return value.  In other words,

> struct R(T)
> {
>     pure bool empty();
>     pure T head();
>     pure R!(T) advance();
> }

is a pure, guaranteed safe-to-resume version of this:

> struct R(T)
> {
>     bool empty();
>     T head();
>     void advance();
> }

The only difference is that instead of writing this:

> for( auto v = r.head; !r.empty; r.advance ) ...

You'd write this:

> for( auto v = r.head; !r.empty; r = r.advance ) ...

>> Honestly, I think the safest option is to *require* resuming to be
>> explicitly stated by the programmer.  It'd be nice if we could
>> automatically account for some cases, but I can't think of any you
>> couldn't escape from.
>>
>> Maybe we should default to non-resumable for now, then re-visit the
>> issue when we have an idea of how people are using ranges.
> 
> I agree. Probably I'll do that, thanks.
> 
> By the way, Walter and I both changed the names of the members to what
> everybody seemed to liked best: front, back, popFront, popBack. No more
> heads and toes.
> 
> 
> Andrei

Cool.  I really can't wait to dive into this stuff.  There are a few
things I've been wanting to write in D2 that I'm holding off until the
range stuff is done so I can give it a workout.

  -- Daniel



More information about the Digitalmars-d mailing list