Coming back, Unique, opDot and whatever else

[Jacob Carlborg]

On 2014-01-17 16:18, Stanislav Blinov wrote:

> As far as I understand it, it can. I mean, I don't see where I would
> violate any of the rules attached to @safe. The only danger zone is
> dereference, and that's protected by throwing. But I commented it out
> because I started having doubts: in my unittests (they're in separate
> module so they have the same access as the user code would) I have three
> simple classes that don't have any @safe attributes on their functions.
> Unique would fail to compile with those ("failed semantic analysis"). So
> it would seem it's rather restrictive. I don't mind imposing
> correctness, but how far should it go?

Just try and @safe and see what happens. These really are the cases 
where you can rely on the compiler telling you when you're do something 
wrong.

> In my opinion, static assert allows for nicer error messages.

Yes, I agree. We had a discussion about this recently. I don't recall 
now, but there are some other advantages of using template constrains. 
Like it's working properly with __traits(compile).

> Oh, yeah, those. Those would go away outside, as private members of a
> module :)

Doesn't matter, private could should look just as good as public ;)

> But that brings another point. No matter how opDot() could be replaced
> (be it alias this or that potential mixin I mentioned), Unique does have
> a public method of its own (release()). How would one resolve collisions
> in this case? I mean, if a wrapped object has its own release() method?
> In the opDot() case, one can write x.opDot().release(). Could similar be
> done with alias this?

I don't think so, but via opDispatch you can do:

x.opDispatch!("release")();

-- 
/Jacob Carlborg