It's impossible to tell if reading or writing an object's variable would call a function because of UFCS or @property. it just hurts because you can't know if it's a function call without looking at implementation.

The most basic example is

obj.val = 1; // actually calls obj.setVal(1)
assert(obj.val == 1); // actually calls obj.getVal(), assertion may fail if getVal or setVal is not implemented correctly. Which is unexpected

To fix this hidden function craziness, UFCS needs to require parantheses, and property function needs to be removed entirely.

On Friday, 27 October 2023 at 12:38:10 UTC, Hors wrote:

obj.val = 1; // actually calls obj.setVal(1)
assert(obj.val == 1); // actually calls obj.getVal(), assertion may fail if getVal or setVal is not implemented correctly. Which is unexpected

why do you need to know if it is a function call?

On Friday, 27 October 2023 at 12:40:39 UTC, duckchess wrote:

obj.val = 1; // actually calls obj.setVal(1)
assert(obj.val == 1); // actually calls obj.getVal(), assertion may fail if getVal or setVal is not implemented correctly. Which is unexpected

Because it kills D's "fast", you may think you just accessing a normal variable but in fact you just calling a lot functions, it can hurt performance. Also for years, obj.val means a variable amd obj.m() means a function. There is no good reason to change that

On Friday, 27 October 2023 at 12:46:37 UTC, Hors wrote:

obj.val = 1; // actually calls obj.setVal(1)
assert(obj.val == 1); // actually calls obj.getVal(), assertion may fail if getVal or setVal is not implemented correctly. Which is unexpected

if they can get inlined, they are, so it doesn't really change anything.

also there absolutely is a good reason for this.

if you have code

struct Foo {
 int x = 5;
}

Foo foo;
writeln(foo.x);

but later realize that you need to have x be a function for any reason, then you don't have to update your sourcecode everywhere. like this:

struct Foo {
int _x;
 int x( = 5) { assert(_x > 0); return _x;}
}

Foo foo;
writeln(foo.x);

On Friday, 27 October 2023 at 12:53:32 UTC, duckchess wrote:

struct Foo {
 int x = 5;
}

Foo foo;
writeln(foo.x);

struct Foo {
int _x;
 int x( = 5) { assert(_x > 0); return _x;}
}

Foo foo;
writeln(foo.x);

It can be useful in some rare cases. But sometimes it does more harm than good, like string operations

str.toLower

calls toLower function which makes a new string every time you use it. So it's incorrect to tell everything can be solved with inline functions

On Friday, 27 October 2023 at 13:37:14 UTC, Hors wrote:

str.toLower

I would recommend to ALWAYS assume that everything is a function call. Because having direct access to object members is a very rare case, and very bad design for a public interface of a library.
So it will only happen in code written by yourself. And then, if you don't like UFCS, don't use it.

UFCS is a huge advantage for reading algorithms in order instead of using lots of parantheses if you want to chain something.

a(b(c(d(e(f()))),5));

which is pretty unreadable will become

f.e.d.c.b(5).a;

which is shorter, more readable and calling order as well as the receiver of additional parameters is now obvious.

UFCS is one of D's major boons. If you work with it for a while, you will start to hate other languages that don't provide it.

On Friday, 27 October 2023 at 12:38:10 UTC, Hors wrote:

obj.val = 1; // actually calls obj.setVal(1)
assert(obj.val == 1); // actually calls obj.getVal(), assertion may fail if getVal or setVal is not implemented correctly. Which is unexpected

If you want to know what function is being called, you can always read the documentation.

Every programming language makes its own choices about which details get shown directly in the code, and which details require you to look something up. Ideally, we would like to show the details people care about, and hide the details they don't care about, but different people care about different things, so there is no choice that will make everyone happy.

If you care very strongly about always being able to tell when a function is being called, maybe D isn't the language for you, and you'd prefer a language like C or Rust. Or maybe D has enough other advantages that this is an annoyance you can learn to live with.

Either way, I'd encourage you to keep in mind that your perspective isn't the only one, and that people who care about different things than you have valid reasons for doing so.

On Friday, 27 October 2023 at 14:18:45 UTC, Dom DiSc wrote:

str.toLower

a(b(c(d(e(f()))),5));

f.e.d.c.b(5).a;

I love UFCS as it makes easier to chain functions. But I have some little worries about confusing variables with functions, and I can't understand what is bad about using variables for a public interface, do we really need a getter and setter functions instead of variables?

On Friday, 27 October 2023 at 17:30:34 UTC, Hors wrote:

It depends. If you have a pure data-type, variables (fields) are ok.
But in an object (class) normally I'd rather nobody messes with the internal stuff. Its just too likely to botch things up. So, yes, in a library I prefer getters (setters not so much for the same reason).
But setters are still better than variables, as they don't allow to take the address of the field controlled by them.

Of course nothing can stop you from shooting yourself in the foot if you really try - but it should not be the first and easiest thing to do.

On Friday, 27 October 2023 at 12:46:37 UTC, Hors wrote:

D1 was released in 2007. And has this feature. And had it before the 1.0 release (I don't know how long before, I can't find it in the changelog).

A bit late to object.

-Steve