2013/2/9 Jonathan M Davis <[email protected]> > 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
