Disable GC entirely

[Rob T]

On Wednesday, 10 April 2013 at 04:32:52 UTC, Manu wrote:
> final on the class means you can't derive it anymore (what's 
> the point of a
> class?),

I think that you'd place final on a derived class, not a base 
class. So it can make perfect sense, although final on the 
methods of a final class makes little sense so it should probably 
be a compiler error.

> and the manual final blocks are totally prone to error.
> In my experience, 90% of functions are not (or rather, should 
> not be)
> virtual. The common (and well performing) case should be 
> default.

Believe it or not, but I actually have been in the reverse 
position more than once, so which way the default should go is 
debatable. In your case I can certainly see why you'd prefer the 
opposite as I've done RT programming before and will be doing it 
again. What could perhaps work is a module level specifier that 
indicates what the defaults should be as a matter of use case 
preference, but I can see that going horribly wrong.

The question I have, is why use a class if you do not need to use 
virtual functions? I think the problem goes a bit deeper than the 
defaults being opposite of what you want. I expect that you'd 
probably want struct inheritance or something like that but 
cannot get it from D?

> Any language with properties can't have virtual-by-default.
> Seriously, .length or any other trivial property that can no 
> longer be
> inlined, or even just called.
> And human error aside, do you really want to have to type final 
> on every
> function? Or indent every line an extra tab level?

Mark your properties as final?

[...]
> I don't want to ban the use of virtual functions. I want to ban 
> the use of
> virtual functions that aren't marked virtual explicitly! ;)
>
> Likewise, I like the GC, I just want to be able to control it.
> Disable auto-collect, explicitly issue collect calls myself at 
> controlled
> moments, and give the collect function a maximum timeout where 
> it will
> yield, and then resume where it left off next time I call it.

I agree 100% and have that need too. I'd go further and also 
prefer the ability to optionally ban certain language features 
from use from within selective parts of my code base. As you say, 
I do not actually want to outright ban the GC or any other 
language feature (I really do use them!!!), it's only the desire 
to be able to have much better control over it for the situations 
that demand precision and certainty.

Having control over D and the GC like what we're taking about in 
here can turn D into a seriously awesome systems language unlike 
any other.

--rt