D's Auto Decoding and You

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, May 19, 2016 13:11:47 jmh530 via Digitalmars-d-announce wrote:
> On Thursday, 19 May 2016 at 12:10:36 UTC, Jonathan M Davis wrote:
> > [snip]
>
> Very informative, as always.
>
> I had not realized the implication of front being called without
> parens, such as front being something that isn't an @property
> function (esp. variable). Are there any ranges in phobos (you can
> think of) that do this?

I'm not aware of any, but there might be some. I think that most of use
pretty much always use @property functions, though the usual reasons for
that don't really apply to Voldemort types. The usual reason to use an
@property function instead of a public variable is that while property
functions emulate variables, they really aren't the same (e.g. taking its
address doesn't have the same semantics, and stuff like incrementing doesn't
normally work with property functions). So, unfortunately, you can't
transparently swap between @property functions and variables, even though
that's theoretically one of the reasons that property functions exist in a
language. But when using a range that's a Voldemort type, you don't even
ever see the type's declaration, and you're only ever supposed to use the
range API on it, so the semantics of variable vs function don't really
matter, since you're not supposed to be doing any of the stuff where it
would matter (e.g. it makes no sense to take the address of front, because
what that means is not specified by the range API and will do different
things with different range implementations).

So, it's arguably better to just use public variables with ranges if
functions like front or empty are just going to return a value, but many of
use just use @property functions out of habit given that in the general
case, it's problematic to use public variables instead of @property
functions (though it _would_ be a nice language enhancement IMHO if
using @property on a variable made it illegal to do anything on it that you
couldn't do on an @property function, since then you could make it a public
variable until refactoring required that it become a function, and changing
it wouldn't break code, whereas now, it might).

- Jonathan M Davis