D's Auto Decoding and You

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, May 17, 2016 17:36:44 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)?

At this point, if anyone ever calls front with parens, they're doing it
wrong. The range API checks that accessing front as if it were a variable
works and _not_ whether calling it as a function works. So, front can be a
variable, an enum (though that wouldn't make much sense), a function, or a
property function. All of those are legal. And properly written range-based
code will work with all of them, because it won't use parens.

The only reason to use parens on front would be if it returned a callable,
and since @property doesn't handle that correctly right now (the first set
of parens still call the function, not what it returns), it really doesn't
work correctly to have a range of callables - at least not and call them
without assigning them to a variable first.

> 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?

IIRC save stopped checking for that around dconf of last year, since given
that it's perfectly legit to call normal functions without parens, and there
is no strong property enforcement, it makes no sense to require that save be
a property function. But I don't think that isInputRange ever checked that
front or empty were property functions (and if it did, I don't know that it
would have worked for them to ever be variables - that would depend on how
the check for whether it was a property function was done).

Regardless, anyone who ever calls front or empty with parens is writing bad
code that will not work generically, because that's not what the range API
dictates. That's one reason why I wish that we had strict property
enforcement, but there's no way that we're getting that at this point. So,
while we do have enforcement of how ranges _can_ be used, we don't have
enforcement of how they _are_ used, and I don't expect that we'll ever get
that.

- Jonathan M Davis