On Thu, May 19, 2016 at 09:21:40AM -0400, Steven Schveighoffer via 
Digitalmars-d-announce wrote:
> On 5/17/16 8:36 PM, H. S. Teoh via Digitalmars-d-announce wrote:
> > On Tue, May 17, 2016 at 08:19:48PM +0000, Vladimir Panteleev via 
> > Digitalmars-d-announce wrote:
> > > On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote:
> > > > However, it's perfectly legal for a front function not to be
> > > > tagged @property.
> > > 
> > > BTW, where is this coming from? Is it simply an emergent property
> > > of the existing implementations of isInputRange and ElementType,
> > > or is it actually by design?
> > 
> > This is very bad. The range API does not mandate that .front must be
> > a function. I often write ranges where .front is an actual struct
> > variable that gets updated by .popFront.  Now you're saying that my
> > range won't work with some code, because they call .front() (which
> > is a compile error when .front is a variable, not a function)?
> My goodness no!
> People, please, my point is simply that is(typeof(someRange.front) ==
> ElementType!(typeof(someRange))) DOESN'T ALWAYS WORK.

OK, so the point is, use ElementType!(typeof(range)) instead of
typeof(range.front)? That works for me. Sorry for the noise. :-P

> > In the old days (i.e., 1-2 years ago), isForwardRange!R will return
> > false if .save is not marked @property. I thought isInputRange!R did
> > the same for .front, or am I imagining things?  Did somebody change
> > this recently?
> You are imagining that someInputRange.front ever required that. In
> fact, it would have had to go out of its way to do so (because
> isInputRange puts no requirements on the *type* of front, except that
> it returns a non-void value).
> But you are right that save did require @property at one time. Not (In
> my opinion) because it meant to, but because it happened to check the
> type of r.save against a type (namely, that .save returns its own
> type).

Ah, so that's where it came from. Now I remember that there were bugs
caused by .save returning something other than the original range type,
which broke certain algorithms. That's probably where the whole .save
requiring @property thing came from.

> At the same time, I fixed all the isXXXRange traits so @property is
> not required anywhere. In particular, isRandomAccessRange required
> r.front to be @property, even when isInputRange didn't (again, IMO
> unintentionally). Here is the PR:
> https://github.com/dlang/phobos/pull/3276

Thanks for the info!


"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my 
big brothers say it it means "no"! -- PJ jr.

Reply via email to