Taking address of properties

[eskimo]

Ok, forget backwards compatibility for a moment, it was just an
additional goody.
On Thu, 2013-02-07 at 19:38 -0500, Steven Schveighoffer wrote:
> Not with @property
> 
> 

That's the point, it would no longer be a property but a simple function
returning ref.

front for arrays would not be a property for two reasons:
1. front is a UFCS function, I think supporting UFCS with properties is
just getting it wrong, have a look at DIP 23 if you don't believe me.

2. My current version, would not allow properties to return ref, but
instead a property is a property if it defines a getter or a setter or
both with the following exact definition:

	@property void a(T val);
	@property T a();

Everything that does not match these requirements can no longer be a
property.

With this restrictions in place, properties cause no problems,
everything works as expected, no weird corner cases. These restrictions
happen to establish property semantics that match the field hiding
pattern and this is what properties are all about, if you ask me.

The moment we stop trying making properties something they aren't,
everything works out.

With optional parentheses in place, accessors to fields via a ref are
still possible, they just no longer conform to the property
specification and thus can not be marked with @property. (And don't need
to be, because: arr.front=something; and something=arr.front; both still
would work)

The gain of this? Clear semantics. If I have a property and I can write
access it, I know that there is a set function. If I have a property I
can read, there has to be a getter. If it is no property, I don't have
any guarantees, which might be fine, depending on the API. (E.g. for
your arr.front example).