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.

On Saturday, 13 September 2025 at 00:43:38 UTC, Brother Bill wrote:

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.

On Saturday, 13 September 2025 at 01:00:17 UTC, Mike Parker wrote:

Mine in the last thread