Partial modification of DIP23 to allow module level property

kenji hara k.hara.pg at gmail.com
Fri Feb 8 22:21:47 PST 2013


2013/2/9 Jonathan M Davis <jmdavisProg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130209/d38933e2/attachment.html>


More information about the Digitalmars-d mailing list