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)? 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? T -- INTEL = Only half of "intelligence".
