I'm back

[deadalnix]

Le 13/11/2012 01:57, Jonathan M Davis a écrit :
> On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote:
>> 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.
>
> So basically, functions like std.array.array would require isInputRange!R&&
> !hasTransientFront!R where hasTransientFront is false for forward ranges and
> is true for input ranges if front returns a mutable reference type or anything
> that might be a mutable reference type (since you can't always tell)?
>
> We'd probably have to add some sort of property for it to check for so that a
> range could declare that it didn't have a transient front (e.g enum
> notTransient = true;) so that there would be fewer cases where a range's front
> would be determined to be transient when it actually wasn't, but that wouldn't
> be hard.
>
> I think that that approach would be far more costly if it were not restricted
> to input ranges, but as so few ranges are not forward ranges and so many
> algorithms require forward ranges anyway, it wouldn't really complicate much,
> though it _is_ still another level of compliction to ranges.
>
>> 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.
>
> It's not all bad in that in almost all cases, a free function peekFront could
> be used, making it so that almost no ranges would have to implement it. But I
> do tend to agree that it would be nice to not have to add more primitives. In
> fact, I'd actually like _reduce_ the number of primitives by gettting rid of
> moveFront and its brethren. They don't seem worth the extra complication to
> me. And even if the declarations for peekFront itself don't cost much, it
> _does_ mean that all ranges have to worry about whether they should use
> peekFront or front, which _does_ complicate things. So, I'm not completely
> enamoured with peekFront either. Then again, I quite like the approach of
> banning transient fronts altogether and insisting that anything which would
> have a transient front use opApply instead.
>
> Certainly, of the two options that you give here, I think that I currently
> prefer the first.
>

I never used moveFront and alike.