D's Auto Decoding and You

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, May 18, 2016 22:23:45 jmh530 via Digitalmars-d-announce wrote:
> On Wednesday, 18 May 2016 at 20:10:09 UTC, Jonathan M Davis wrote:
> > At this point, if anyone ever calls front with parens, they're
> > doing it wrong.
>
> Is this true of all @property functions? Should this be noted in
> the spec? Should it be an error? If it shouldn't be an error, is
> it really such a bad thing?

It makes _no_ sense to use parens on a typical @property function. The whole
point of properties is that they act like variables. If you're marking a
function with @property, you're clearly indicating that it's intended to be
treated as if it were a variable and not as a function. So, in principle, if
you're using parens on a property function, the parens should be used on the
return value and _not_ the function. That being said, we've never ended up
with property enforcement of any kind being added to the language.  So,
while the compiler _should_ require that an @property function be called
without parens, it doesn't. And without that requirement, @property really
doesn't do much. If we want properties to work where the type is a callable
like a delegate (e.g. you have a range of delegates, so front returns a
delegate), then it's going to need to change so that using parens on an
@property function actually uses the paren on the return value, and without
that @property is nothing more than documentation. So, right now, @property
is pretty much just documentation about how the person who wrote the code
expects you to use it. It doesn't really do anything. It does have some
affect with regards to typeof, but overall, it does nothing.

Now, that being said, when I was talking about calling front with parens, I
wasn't really talking about property functions - though front is frequently
a property function. Rather, my point was that isInputRange requires that
this code compile:

        R r = R.init;     // can define a range object
        if (r.empty) {}   // can test for empty
        r.popFront();     // can invoke popFront()
        auto h = r.front; // can get the front of the range

If that code compiles with a given type, then that type can be used as an
input range. That API is in the API defined for input ranegs. It does _not_
call front with parens nor does it call empty with parens. Rather, it
explicitly uses them _without_ parens. So, they could be property functions,
or variables, or normal functions that just don't get called with parens, or
anything else that can be used without parens and compile with that code.
So, if you write a range-based algorithm that uses parens on empty or front,
then you're writing an algorithm that does not follow the range API and
which will not work with many ranges.  The range API does _not_ guarantee
that either front or empty can be used with parens. It guarantees that they
can be used _without_ them. So, if your code ever uses parens on front or
empty, then it's using the range API incorrectly and risks not compiling
with many ranges.

- Jonathan M Davis