On 5/1/14, 3:17 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 01, 2014 at 02:29:22PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 5/1/14, 1:19 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 01, 2014 at 01:03:06PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 5/1/14, 12:52 PM, "Nordlöw" wrote:
into a class. I'm inclined to say that we should outright
prohibit that,
That can't happen.
Why is that?
(1) Too much breakage, (2) would disallow a ton of correct code, (3)
no reasonable alternative to propose. We'd essentially hang our
users out to dry. -- Andrei
Isn't this what we're already doing by (eventually) getting rid of
class dtors?
Not even close. (1) A lot less breakage, (2) disallowed code was
already not guaranteed to work, (3) reasonable alternatives exist.
[...]
Argh, I feel like this discussion is going in circles. Do I really have
to spell everything out just to make my point?
1) Today, a struct with a dtor will have the dtor invoked when the
struct goes out of scope.
2) Today, the language allows you to put such a struct in a class as a
member variable.
3) Today, the struct dtor of the class member will get invoked when the
class dtor is invoked.
4) Andrei is proposing to deprecate class dtors, meaning that at some
point they will no longer exist.
5) When that day comes, class dtors will no longer exist.
6) Since class dtors were the only thing that cleaned up the struct
member variables by invoking their dtors, that means the struct dtor
will *never* get invoked.
Since the struct dtor will *never* get invoked, it makes no sense to
define one in the first place.
Here's where the point derails. A struct may be preexisting; the
decision to define a destructor for it and the decision to use
polymorphism for an object that needs that structure are most of the
time distinct.
Andrei
