Is defining get/set methods for every field overkill?

On Monday, 21 November 2022 at 00:29:12 UTC, thebluepandabear 
wrote:
>> .. not to mention, I'd be out of job if I stopped writing 
>> getters/setters ;-)
>
> I value your input in this discussion, you have brought some 
> good points.
>
> Out of interest, what type of industry-level software are you 
> creating with D? I don't know much companies using D 
> commercially.

As someone else mentioned in this thread, there are some 
'arbitrary changes' in D, for example, to the traditional concept 
of the class type, as being a user-defined type for encapsulating 
data and methods that operate on that data.

That is, the module, not the class, is the unit of encapsulation 
in D.

In addition, public is the default visibility in a class in D, 
which also goes against the traditional concept of using an 
encapsulated user-defined data type in conjunction with 
'information hiding' (or access controls, depending on what 
terminology you want to use).

These decisions no doubt, are design decisions, and not 
accidental, I presume.

These decisions have consequences of course.

You should be completely aware of these changes in D, *before* 
embarking on using classes in D. Some would say those 
consequences are benefical, while others would reject that 
proposition, entirely ;-)

As such I leave it to the designer(s) of D to better explain 
their reasoning.

These changes by themself rule out the use of D in our 
environment.

"..utility functions operating on data structures. Welcome to 
1972!"

There are many other reasons also of course, which frankly are 
unrelated to (and more important) than the above.

But otherwise, I find D to be an enjoyable hobby language, 
particulary for lower-level programming, to both use and explore 
its capabilities.

There are of course some companies using it commercially. But not 
the company I work for.