Discuss: Classes are well supported in D, with Design by Contracts. Shouldn't we take advantage of that?

[Mike Parker]

On Saturday, 13 September 2025 at 00:43:38 UTC, Brother Bill 
wrote:
> I'm not clear about why 'class'es are on the 'avoid' list.
>
> D has excellent support for Single inheritance, Interfaces, 
> Design by Contract (DbC), GC, etc.
> I'm aware that there is a small run time cost for selecting the 
> right virtual method.
>
> To reduce this cost, one must final-ize methods that don't need 
> to be overridden.
>
> Using classes is a major reason that I chose D.
> Outside of Eiffel language, D comes closest to supporting DbC.
> Even .NET has abandoned supporting DbC.

What 'avoid list'? Plenty of D programmers use classes. If they 
make sense for a specific scenario according to how you want to 
architect your software, then go ahead and use them.

Some people prefer to avoid them because they, by default, 
require GC allocation. There are two basic concepts to keep in 
mind:

* the more often you allocate from the GC, the more opportunities 
it has to run;
* the more memory you allocate from the GC, the more memory it 
has to scan.

In other words, allocate only what you really need and avoid 
allocations in hotspots. The goal is to minimize GC pressure.

There are different strategies to get there, like using structs 
for POD types or when you don't really need inheritance, 
preallocating before hot spots, using free lists to recycle 
objects, etc. Some of that is architectural and should be decided 
beforehand, some of it is only what you think about when you need 
to optimize.

Regardless, you'll be fine most of the time without needing to 
worry about most of that. Just remember that D is not Java and 
everything doesn't need to be a class.