Beta D 2.069.0-b1

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, October 08, 2015 15:00:15 Martin Nowak via Digitalmars-d-announce wrote:
> On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:
> > On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
> >> Does that mean @property has no effect anymore ?
> >
> > @property never actually worked anyway. It is still my hope
> > that it will be correctly implemented some day though
>
> I think http://wiki.dlang.org/DIP23 reflects the most accurate
> roadmap for @property, basically being permissive w.r.t. parens.
> And who really cares whether it's rng.popFront or rng.popFront()?

What's problematic with regards to requiring parens or not is when the
symbol _can't_ be called with parens. So, whether popFront is called with
parens or not realistically doesn't matter, because it's going to be a
function (theoretically, it could be a member variable that implements
opCall, but that's so unlikely that there really is no need to worry about
it IMHO). However, it _does_ matter whether something that's intended to be
used as a property or not is called with parens. Code which uses parens on
save or front is not going to work with all ranges, because they're not
always functions. So - at least in templated code - it needs to be clear
when a symbol is treated as a property, and it cannot be called with parens
if it is supposed to be a property. Enforcing that @property is called
without parens wouldn't entirely fix that problem, but it would help catch
cases where someone actually used parens when they shouldn't have.

Regardless, what we pretty much need to do with @property at some point is
make is that it's used to make it so that a single pair of parens operate on
the return value rather than the function even if we don't do anything else
with @property - otherwise properties which are delegates or other callables
aren't possible. Having DIP 23 be implemented would be great though.

- Jonathan M Davis