Re: front stability

On 6/30/16 7:50 PM, Walter Bright wrote: On 6/2/2016 5:51 AM, Steven Schveighoffer wrote: I have always treated ranges with this expectation: 1. front gets you the current element of the range. Calling front multiple times without calling popFront should get you the same value. 2. popFront move

Re: front stability

On 6/30/2016 8:32 AM, Steven Schveighoffer wrote: This doesn't solve it, and it can't be solved -- halting problem. We have some expectations that are assumed and some that are mechanically tested. This PR clarifies the assumptions. I made some range drivers that brutally test the protocol: ht

Re: front stability

On 6/2/2016 8:21 AM, deadalnix wrote: I opened some bugs about that in the past, but got shut down. It is especially problematic since some ranges (like filter) are calling front several time when iterating. Please reopen them.

Re: front stability

On 6/2/2016 5:51 AM, Steven Schveighoffer wrote: I have always treated ranges with this expectation: 1. front gets you the current element of the range. Calling front multiple times without calling popFront should get you the same value. 2. popFront moves you to the next element of the range if

Re: front stability

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer wrote: The counter-argument seems to be that if you cache the front element, then then making a copy of the range via take can repeat the cached element[4]. I find this argument severely lacking -- non-forward ranges are not meant t

Re: front stability

On Thursday, 30 June 2016 at 19:34:47 UTC, H. S. Teoh wrote: arbitrary type. It doesn't seem to make sense that the assignment operator should suddenly be prohibited just because it happens to have members named .front, .empty, .popFront. Seems like this could be resolved by requiring all rang

Re: front stability

On Thu, Jun 30, 2016 at 07:23:24PM +, default0 via Digitalmars-d wrote: > On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer wrote: [...] [...] > > Unfortunately, for the likes of forward ranges, copying mainly > > always does the same thing as .save does. So you have tons and tons

Re: front stability

On Thursday, 30 June 2016 at 18:07:41 UTC, Steven Schveighoffer wrote: On 6/30/16 11:56 AM, Mathias Lang via Digitalmars-d wrote: 2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d >: I have always treated ranges with this expectation: I

Re: front stability

On 6/30/16 11:56 AM, Mathias Lang via Digitalmars-d wrote: 2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d mailto:digitalmars-d@puremagic.com>>: I have always treated ranges with this expectation: I think the case is pretty clear here, and I'm in agreement with you. I ju

Re: front stability

2016-06-02 14:51 GMT+02:00 Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com>: > I have always treated ranges with this expectation: > > I think the case is pretty clear here, and I'm in agreement with you. I just want to add a note on the following point: 2016-06-02 14:51 GMT+

Re: front stability

On 6/30/16 10:59 AM, jmh530 wrote: On Thursday, 30 June 2016 at 14:17:22 UTC, Steven Schveighoffer wrote: Jack Stouffer has created a PR to formalize this. Please comment if you have objections (the group that argued for current generate behavior was absent from this post that was meant to be

Re: front stability

On Thursday, 30 June 2016 at 14:59:11 UTC, jmh530 wrote: It looks like this is just documentation changes. This really doesn't prevent anyone from making a Range that violates front stability. No, but what it will do is to make it clear that these are either bugs or intended behavior, as this

Re: front stability

On Thursday, 30 June 2016 at 14:17:22 UTC, Steven Schveighoffer wrote: Jack Stouffer has created a PR to formalize this. Please comment if you have objections (the group that argued for current generate behavior was absent from this post that was meant to be a debate). I think this is the rig

Re: front stability

On 6/2/16 8:51 AM, Steven Schveighoffer wrote: I have always treated ranges with this expectation: 1. front gets you the current element of the range. Calling front multiple times without calling popFront should get you the same value. 2. popFront moves you to the next element of the range if it

Re: front stability

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer wrote: [...] I opened some bugs about that in the past, but got shut down. It is especially problematic since some ranges (like filter) are calling front several time when iterating.

Re: front stability

On 06/02/2016 02:51 PM, Steven Schveighoffer wrote: For example, generate.popFrontN does nothing. generate.drop does nothing. And of course, calling front multiple times does not yield the same answer, unless you provide a lambda that does the same thing every time (a useless case). That's just

Re: front stability

On Thursday, June 02, 2016 08:51:18 Steven Schveighoffer via Digitalmars-d wrote: > I'd say violating the expectations of what popFront and front do is more > egregious than a particular use case, no matter how valid that case is. > I'd like to fix this bug, but I see there were quite a few major

Re: front stability

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer wrote: 1. front gets you the current element of the range. Calling front multiple times without calling popFront should get you the same value. 2. popFront moves you to the next element of the range if it exists. Agreed. To quote

Re: front stability

On Thursday, 2 June 2016 at 12:51:18 UTC, Steven Schveighoffer wrote: I have always treated ranges with this expectation: So have I. It's troubling that's not how some of them work. Atila