Is defining get/set methods for every field overkill?

[Dukc]

On Saturday, 19 November 2022 at 09:26:49 UTC, Andrey Zherikov 
wrote:
> On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear 
> wrote:
>> That's the point many people have given here which is not 
>> convincing him, even though it is quite great.
>>
>> I think we all know the answer here 😂
>
> IMHO you are both right :)
> You are speaking about API compatibility, `[]() {}()` speaks 
> about ABI compatibility. The latter makes sense in long-running 
> production software. So we know that there are no issues in API 
> compatibility but we don't know anything about ABI.

Yes, this is a good summary. Redefining a raw field as a 
getter/setter pair keeps the API but breaks the ABI, so in some 
cases conservative getters/setters can be justified.

Another problem with raw fields:

```D
struct S{int field;}

@safe clientCode()
{   auto s = new S();
     doSomething(&s.field);
}
```

This will break if S is rewritten as

```D
struct S
{   int field_;
     auto field(){return field_;}
     auto field(int val){return field_ = val;}
}
```

I though at first that breakage could still be avoided by instead 
writing

```D
struct S
{   int field_;
     ref field(){return field_;}
}
```

...but I tested and actually it does not work because in this 
case `&s.field` takes the address of the getter function, not the 
field.

Now, despite all this I don't think it'd be a good idea to write 
everything to getters/setters just in case. The binary interface 
issue is frankly secondary: most structs and classes are just 
compiled along with their client code. And even separately 
compiled libraries only have to do this if they strive to provide 
a stable ABI between releases, which is not nearly always the 
case. Nor needs to be.

But still the pointer problem in the above example stands, so 
conservative getters/setters are justified in an API that's used 
widely enough. But probably not for something internal to a ten 
thousand line long package.