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
