Invariant for default construction

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 21 05:48:11 PST 2014


On 12/20/14 10:24 PM, Walter Bright wrote:
> On 12/20/2014 7:11 PM, Steven Schveighoffer wrote:
>> Wouldn't a tree own its nodes?
>
> I've replied to this repeatedly. Think of a symbol table tree, in which
> symbols are looked up. References to found symbols are then inserted
> into the AST.

But doesn't the AST allocate it's nodes, with a reference to the symbol? 
I'm ignorant of how AST is designed, but when, for instance, you insert 
an element into a RedBlackTree, the RedBlackTree owns the node, but not 
the reference to the element (if it's a reference-style element).

> Building a language design that REQUIRES ownership of all references in
> an object would be cripplingly limited.

This strawman is not what I or anyone else said.

What we are saying is, do not build a language which assumes NO 
ownership of any references.

>
>
>> I find the idea of a tree checking its nodes to
>> ensure it's properly sorted (or maybe properly balanced) cannot
>> possibly be done
>> without actually looking at its nodes.
>>
>> How do you propose one would check that invariant?
>
> Not using invariant() to do it. The existence of invariant() with
> language support does not mean that there aren't other ways to do it, or
> that invariant() must be universally applicable to everything.

This is kind of silly. What you are proposing is to do this:

void anyfunc()
in
{
    assert(theRealInvariant());
}
out
{
    assert(theRealInvariant());
}
body
{
    ...
}

Basically, you have to re-implement invariant manually on every single 
function, except on the destructor.

Why couldn't you limit invariants to not being called in the destructor, 
but you could call it from the destructor if you wanted? Especially 
since that's the way it was. In fact, we can do that today.

Alternatively, you could pass a parameter to invariant that indicates 
whether it's in the destructor or not.

What you are saying with this change is invariant is strictly for value 
types only.

-Steve


More information about the Digitalmars-d mailing list