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


INTEL = Only half of "intelligence".

Reply via email to