2013/2/9 Jonathan M Davis <jmdavisProg@gmx.com>
And why is it that the global function gets to be a setter property and the
UFCS function doesn't? What's the advantage in choosing the UFCS function as
the one that has to be a normal function which just happens to be called
without parens (but could be called with them) over choosing the global getter
property to be the one that's a function that can be called without parens?

To get a balance between rule simplicity and actually possible use cases.

In my long thought, I have found that @property annotation is not really necessary for UFCS getters (e.g. std.array.front). 
After the implementation of "optional paranthesis" feature which described in DIP23, a use of UFCS getter will work as same as now - using left hand side of assignment (e.g. arr.front = value) and even getting address of returned ref (auto ptr = &arr.front) . Then, we can use a @property function defined in module level and has exactly one parameter as a module level setter without ambiguity. This is much reasonable benefit compared to the cost.
 
I'd much rather see the global getter have to be declared without @property
(and rely an the ability to be called without parens but be unable to enforce
it).

I think it will introduce an inconsistency against method @property functions, as follows:

- Method property should have zero parameter for getter, or one parameter for setter.
  Both should be annotated with @property.
- Module level property should have zero parameter for getter, but MUST not be annotated with @property.
  Module level property should have one parameter for setter and should be annotated with @property.

This is much complicated than my proposed sentence:
 
2. A @property may have EXACTLY ZERO or EXACTLY ONE parameter, without counting the implicit this parameter if at all.
The ZERO-parameter version is ALWAYS a getter, and the ONE-parameter version is ALWAYS a setter.
There's no variadics, defaulted parameters, and such.

And I _definitely_ wouldn't want to set a precedence for front to be
declared as a non-property function. It needs to be consistently called
without parens to work in generic code, and if arrays are able to use front
with parens, then we definitely risk a lot of range-based functions being
written incorrectly due to the fact that far too often, range-based functions
only end up being tested with arrays, and in that case, the parens wouldn't
cause an error like they should. It wouldn't be caught until someone actually
tried it with another type of range (possibly much later). Granted, the writer
of the range-based function should have tested it better, but given that
arrays are by far the most common type of range, I think that it's just asking
for trouble to allow their front or back to be used with parens.

Sorry I cannot imagine an actual use case you are considering.

Kenji Hara