DIP Proposal: @manualScoped to prevent automatic field destruction
FeepingCreature
feepingcreature at gmail.com
Fri Jul 27 12:00:02 UTC 2018
On Friday, 27 July 2018 at 11:44:10 UTC, aliak wrote:
> A) I'd suggest "@nodestruct" instead, since it sounds like that
> what it's supposed to do?
Yes-ish, but it's also supposed to fill the hole in the
typesystem created by T.init, and "you can only assign T.init to
types marked @nodestruct" sounds kind of magic.
> B) is this basically for the case of invariants being run
> before destructors where T.init are not valid runtime instances
> of T?
Yep, that's the reason I'm looking at it.
> C) If it is, then this seems to me that this is something that
> should just work without a programmer needing to know about how
> T.init and invariants are implemented, so an implementation
> that doesn't call invariants before a destructor only if an
> instance was never constructed at runtime is maybe the way to
> go? Though I have no idea how possible that is.
>
Basically impossible without giving every type a hidden "bool
initialized" field. So, basically impossible.
The advantage of doing it with @manualScoped is twofold. First,
it also covers the case of opAssign methods taking parameters
that don't need to be destroyed at scope end. Second, even a
constructor may return a T.init (and, for instance, increment a
static variable), so if being T.init skipped the destructor we'd
again get a constructor/destructor mismatch. @manualScoped makes
it clear this is a variable that contains a value with a manually
managed lifetime, so users take responsibility to call
moveEmplace/destroy as required to make constructor/destructor
calls match up, which is the goal.
Basically, think of a @manualScoped variable as a "weak value" in
analogy to weak references.
> Cheers,
> - Ali
>
> maybe your PR where invariants is not called before a
> destructor if an instance is a T.init is maybe the way to go?
> [0]
The PR itself was just a way to hack around this. The problem
isn't the invariant check on destruction, the problem is the
destruction without the matching construction.
More information about the Digitalmars-d
mailing list