Classes or stucts :: Newbie

[Nick Voronin]

On Sun, 19 Dec 2010 14:38:17 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Sunday 19 December 2010 14:26:19 bearophile wrote:
> > Jonathan M Davis:
> > > There will be a library solution to do it, but again, it's unsafe.
> > 
> > It can be safer if the compiler gives some help. For me it's one of the
> > important unfinished parts of D.
> 
> Whereas, I would argue that it's completely unnecessary. structs and classes 
> serve different purposes. There is no need for scoped classes. They may 
> perodically be useful, but on the whole, they're completely unnecessary.

How do you define a need for scoped classes? 

I see two aspects there: first is having destructor called at known point rather than arbitrarily, second is performance.

It looks perfectly reasonable for me to want to have first. Do you know why things which makes program act more deterministic are shunned from D? Does it really add so much to safety that it is worth reducing programmer's control?

Second is irrelevant to types, if I want to speed up some code and can do it by placing things on stack rather than in heap -- what does it matter if it is class or struct or integer? We have alloca() anyway, so removing modifier won't save me from myself, just push me to more C-like code. Which kind of defeats the purpose of using D.

> The compiler can help, but it can't fix the problem any more that it can 
> guarantee that a pointer to a local variable doesn't escape once you've passed 
> it to another function.

Absolutely. Yet we won't have library solution for pointers instead of language support (hopefully)? :) I think it all goes against "being practical" as an objective of the language. Safety is important but you don't achieve safety by means of making unsafe thing unconvenient and inefficient. If there is emplace() then there is no reason not to have scope storage class. At least looking from user's POV. I don't know how hard it is on the compiler.

> In _some_ circumstances, it can catch escaping pointers 
> and references, but in the general case, it can't.

In _general_ case there is no safety in D. With all low-level capabilities one can always defeat compiler. Removing intermediate-level safer (yet unsafe) capabilities arguabily gains nothing but frustration. I'm all for encouraging good practices, but this is different.

-- 
Nick Voronin <elfy.nv at gmail.com>