Is there a way to enforce UFCS?

Dom DiSc dominikus at scherkl.de
Thu Jan 5 14:32:17 UTC 2023


On Wednesday, 4 January 2023 at 14:21:46 UTC, bauss wrote:
> ```d
> class Foo {
>   int bar;
>
>   void setBar(Foo foo, int value) {
>     foo.bar = value;
>   }
> }
>
> void main() {
>   foo.setBar(100); // Not UFCS - just method call to the class
>   foo.setBar = 100; // Not UFCS - simply a setter function call 
> (equal to the above)
>   setBar(foo, 100); // Error
> }
> ```

I think this is really another usecase for @property: we should 
forbid the function call syntax for them (so one needs to use 
them like a variable).
This is useful to enable library authors to enforce this, so that 
if a property is replaced by a variable (e.g. during 
refactoring), it's not a braking change for the users of the 
library.
Else it could be that setters or getters are directly called, 
which would not compile anymore with a variable (that doesn't 
have getters or setters).

@properties are intended to be used like variables - the only 
differences (and the reason why they exist) is the read or write 
protection they provide, and that they may be calculated on the 
fly (not stored in memory at all). That they are realized with a 
construct that looks similar to (a pair of) functions should be 
completely transparent for the user of a library.

Properties are not functions. If you want a function, use a 
function. If @properties would be the same as functions, they are 
superfluous garbage. Either make something useful out of them or 
remove them.



More information about the Digitalmars-d-learn mailing list