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.
