D's hidden function calls getting crazier.

[duckchess]

On Friday, 27 October 2023 at 12:46:37 UTC, Hors wrote:
> On Friday, 27 October 2023 at 12:40:39 UTC, duckchess wrote:
>> On Friday, 27 October 2023 at 12:38:10 UTC, Hors wrote:
>>> 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.
>>
>> why do you need to know if it is a function call?
>
> 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

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
```d
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:

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

Foo foo;
writeln(foo.x);
```