I'm back

deadalnix deadalnix at gmail.com
Mon Nov 12 16:07:24 PST 2012


Le 13/11/2012 00:57, Andrei Alexandrescu a écrit :
> On 11/12/12 3:14 PM, Jonathan M Davis wrote:
>> On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
>>>> Topic on range transience probably, as it is
>>>> almost concluded.
>>>
>>> I'm leaning toward doing nothing about this.
>>
>> As it stands, most everything assumes that front is not transient. But
>> then we
>> have ByLine and ByChunk. So, they just plain don't work as ranges for
>> the most
>> part, but they're in the standard library. Either they need to stop being
>> transient or to stop being ranges (and use opApply), or we need to
>> decide on a
>> way to support them being transient as ranges.
>>
>> The best options at this point seem to be to either insist that all
>> ranges have
>> non-transient fronts (and adjust ByLine and ByChunk accordingly) or to
>> go with
>> the peekFront idea. The peekFront idea probably needs some examination
>> though
>> in order to work on the kinks (e.g. letting peekFront and front return
>> different
>> types might be useful in some circumstances, but in general, it's
>> likely to
>> cause a lot of problems if they don't both return ElementType!R).
>
> Here are two thoughts:
>
> 1. The notion of "this is an input range that is not a forward range,
> AND the element type has mutable indirections so it's not a proper value
> type" is a very close approximation of transiency. We could define that
> as a trait and have interested algorithms consult it.
>
> 2. I'm reversing my attitude toward peekFront for the simple reason I've
> been there: moveFront, moveBack, and moveAt. And it's not a pretty place
> to be in. As soon as we're discussing peekFront there's the question of
> supporting peekBack and peekAt. I'm pretty sure people, if sufficiently
> motivated, will find examples of bidirectional and random-access
> transitory ranges that motivate such primitives.
>

I understand your point, so why not simply state that range MUST NOT be 
transient at all ? This is the solution that introduce nothing.


More information about the Digitalmars-d mailing list