Consider the following:

struct JustZeroes {
    int front = 0;
    enum bool = false;
    void popFront() {}
}

Is that guaranteed to work as an input range? I ask because I've so often written:

  T current;
  @property T front() { return current; }

that it just seems silly to me to write the extra lines when current == front. I realize there is a small difference there, in that front is not an lvalue here, but is when it is a direct member, but other than that, is this an acceptable form? Or does the lvalue thing mean it is strongly discouraged?

On 12/12/2013 08:19 AM, Adam D. Ruppe wrote:

> Consider the following:
>
> struct JustZeroes {
>      int front = 0;
>      enum bool = false;

You meant empty = false;

>      void popFront() {}
> }
>
> Is that guaranteed to work as an input range?

Yes it is perfectly fine. And if it works for empty it should work for front. ;) The presence of std.range.hasLvalueElements is another indicator that it fine. Finally, if std.range.isInputRange returns true, it is an InputRange.

Ali

I'd expect http://dlang.org/phobos/std_range.html#.isInputRange to be "standard" answer to this question (== yes, it is ok).

Adam D. Ruppe:

> Consider the following:
>
> struct JustZeroes {
>     int front = 0;
>     enum bool = false;
>     void popFront() {}
> }
>
> Is that guaranteed to work as an input range?

It seems similar to 0.repeat

When you are not sure add a static assert below the range, to verify it is the kind of range you want.

Bye,
bearophile

On Thu, Dec 12, 2013 at 05:19:28PM +0100, Adam D. Ruppe wrote:
> Consider the following:
> 
> struct JustZeroes {
>     int front = 0;
>     enum bool = false;
>     void popFront() {}
> }
> 
> Is that guaranteed to work as an input range? I ask because I've so often written:
> 
>   T current;
>   @property T front() { return current; }
> 
> that it just seems silly to me to write the extra lines when current == front. I realize there is a small difference there, in that front is not an lvalue here, but is when it is a direct member, but other than that, is this an acceptable form? Or does the lvalue thing mean it is strongly discouraged?

I do this with my own ranges sometimes. Sometimes, it's more performant to precompute the value of .front and store it (as .front), and have .popFront compute the next value, than to have .front compute the value every time. AFAICT, this is perfectly fine and should work with Phobos seamlessly. The power of ducktyping!


T

-- 
Quack!

On 12/12/13 17:19, Adam D. Ruppe wrote:
> Is that guaranteed to work as an input range? I ask because I've so often written:
>
>    T current;
>    @property T front() { return current; }
>
> that it just seems silly to me to write the extra lines when current == front. I
> realize there is a small difference there, in that front is not an lvalue here,
> but is when it is a direct member, but other than that, is this an acceptable
> form? Or does the lvalue thing mean it is strongly discouraged?

Isn't the issue here not whether or not it will work in terms of your type being a range, and more that it means that users can overwrite the value of front?

It seems to me that it would be OK for personal projects where you control 100% of the code, but it wouldn't be acceptable for stuff that's intended to be used by other people.

On 12/12/13 17:51, Joseph Rushton Wakeling wrote:
> Isn't the issue here not whether or not it will work in terms of your type being
> a range, and more that it means that users can overwrite the value of front?

... if OTOH the idea is that front never changes, then I'd suggest an enum, as is already common for empty (e.g. in RNGs, you typically get "enum bool empty = false").

On Thursday, 12 December 2013 at 16:45:05 UTC, H. S. Teoh wrote:
> I do this with my own ranges sometimes. Sometimes, it's more performant to precompute the value of .front and store it (as .front)

Yeah, that's exactly what I was doing here.

My question was mostly on if there's the chance that someone will call front() but looks like that isn't supposed to happen and is wrong if it does, so cool.

On Thursday, 12 December 2013 at 16:52:12 UTC, Joseph Rushton Wakeling wrote:
> and more that it means that users can overwrite the value of front?

Yeah, that's what I meant by the lvalue thing, though most the time I don't think it is even that big of a deal if it gets overwritten since the main use of ranges for me is foreach loops anyway. But yeah, that is a good point.

On Thursday, 12 December 2013 at 16:52:12 UTC, Joseph Rushton Wakeling wrote:
> On 12/12/13 17:19, Adam D. Ruppe wrote:
>> Is that guaranteed to work as an input range? I ask because I've so often written:
>>
>>   T current;
>>   @property T front() { return current; }
>>
>> that it just seems silly to me to write the extra lines when current == front. I
>> realize there is a small difference there, in that front is not an lvalue here,
>> but is when it is a direct member, but other than that, is this an acceptable
>> form? Or does the lvalue thing mean it is strongly discouraged?
>
> Isn't the issue here not whether or not it will work in terms of your type being a range, and more that it means that users can overwrite the value of front?
>
> It seems to me that it would be OK for personal projects where you control 100% of the code, but it wouldn't be acceptable for stuff that's intended to be used by other people.

Being able to assign to front is a feature of an output range.