System programming in D (Was: The God Language)

[Walter Bright]

On 1/4/2012 3:26 PM, Manu wrote:
> Is this true? Surely the REAL reason to use classes is to allocate using the GC?
> Aren't struct's allocated on the stack, and passed to functions by value? Do I
> need to start using the ref keyword to use GC allocated structs?

struct S { ... }

S* s = new S(); // struct is allocated on the GC


> I have never written a class in any language where the ratio of virtual to
> non-virtual functions is more than 1:10 or so... requiring that one explicitly
> declared the vastly more common case seems crazy.

I found the opposite to be true when I use OOP in C++. Either scheme is valid, 
saying one is crazy or prohibitive way overstates the case.

(I have had a lot of bad experiences in C++ with accidentally overriding a 
non-virtual function. It's perfectly valid in C++, but man does your code behave 
bizarrely when you do it.)

In any sensible class design, you're going to have to decide which functions are 
overrideable and which are not. There's no way around it, and no magic default.


> The thing I'm most worried about is people forgetting to declare 'final:' on a
> class, or junior programmers who DON'T declare final, perhaps because they don't
> understand it, or perhaps because they have 1-2 true-virtuals, and the rest are
> just defined in the same place... This is DANGEROUS.

It isn't dangerous, it is just less optimal. What is dangerous is (in C++) the 
ability to override a non-virtual function, and the use of non-virtual destructors.

It's also true that D's design makes it possible for a compiler to make direct 
calls if it is doing whole-program analysis and determines that there are no 
overrides of it.