More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/1/14, 7:17 AM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Apr 30, 2014 at 04:33:23PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> No, allowing the user to specify a struct with a dtor, and put that
> struct in a class, and then saying "nyah nyah class dtors don't exist
> anymore so your struct will never destruct" -- *that* is bad decision
> making. At the very least, the compiler should complain loudly and
> clearly that structs with dtors should not be put inside a class. Isn't
> this what D philosophy is supposed to be? Things should *work* by
> default, and unexpected behaviour (dtor never gets called) should only
> happen when the user explicitly asks for it.

Problem is there's a lot of correct code that e.g. closes the File 
members properly etc. All that code would be disable together with the 
risky code.

>>> That kind of under-specification is the source of endless
>>> hard-to-trace bugs, gotchas, unfixable issues, and holes in the type
>>> system. If we're going to have dtors at all, let's do it *right*.
>>> Guarantee they always work, and reject all usages that break this
>>> guarantee (like putting a struct with dtor inside a class, putting it
>>> inside a dynamic array in GC memory, etc.). If we can't guarantee
>>> anything at all, then let's not have dtors at all.  Trying to stay in
>>> the gray zone in between does nothing but cause endless problems down
>>> the road. Not to mention language smells. What's the use of a feature
>>> that only sometimes works, where "sometimes" is un(der)specified,
>>> left to implementation, or depends on undefined behaviour?
>>
>> A lot of other languages have such imperfections, and nobody raises a
>> brow.
> [...]
>
> I thought D is here because we want to do better than that?

Better != perfection at all costs.


Andrei