On Mon, Nov 12, 2012 at 12:28:14PM -0800, Andrei Alexandrescu wrote:
> On 11/12/12 11:45 AM, deadalnix wrote:
[...]
> >Topic on range transience probably, as it is almost concluded.
> 
> I'm leaning toward doing nothing about this.
[...]

Please don't. This is an issue that *needs* to be addressed, one way or another. Even if it's just to declare that transient ranges are illegal, and move on with no code changes. Leaving things the way they are currently only introduces subtle bugs and indeterminate behaviour, and is not acceptable.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.

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).

- Jonathan M Davis

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.


Andrei

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.

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.

- Jonathan M Davis

On Monday, 12 November 2012 at 20:54:39 UTC, Jonathan M Davis wrote:
> On Monday, November 12, 2012 21:24:06 Rob T wrote:
>> Long discussion on const ref,
>> http://forum.dlang.org/thread/yhnbcocwxnbutylfeoxi@forum.dlang.org
>> 
>> here's the summary thread
>> http://forum.dlang.org/thread/zteryxwxyngvyqvukqkm@forum.dlang.org
>
> Yeah. You have some very strong views and that issue which almost no one else actually understands, so a lot of people keep
> pushing for D's const ref to act like C++'s const&.

Yes, I'm one of these people (and a persistent one I might add :D) as this issue really bothers me. I'm convinced we can settle it, so I'd be glad if you took the time to look at the 2nd linked thread, Andrei.

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.

On 11/12/12 5:40 PM, deadalnix wrote:
> I never used moveFront and alike.

They're used by algorithms that you might be using.

Andrei

Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :
> On 11/12/12 5:40 PM, deadalnix wrote:
>> I never used moveFront and alike.
>
> They're used by algorithms that you might be using.
>
> Andrei

I'm not saying they are useless, or that I never used them under the hood.

On 11/12/12 6:29 PM, deadalnix wrote:
> Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :
>> On 11/12/12 5:40 PM, deadalnix wrote:
>>> I never used moveFront and alike.
>>
>> They're used by algorithms that you might be using.
>>
>> Andrei
>
> I'm not saying they are useless, or that I never used them under the hood.

Then what is it that you are saying? Honest question.

Andrei