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
