On Friday, 17 January 2014 at 07:34:58 UTC, Jacob Carlborg wrote:
opDot has been replaced with opDispatch [1] and "alias this" [2].
I know, it was just a shortcut "for now". Although alias this is of little help in case of Unique, at least without additional "middle man". After all, the whole purpose of Unique is to swallow the reference and never let anyone outside the family lay hands on it :)
Surely, opDot() is not a panacea either, you can always steal a reference by doing auto x = u.opDot().
I was thinking about brewing up a middle man using reflection. A hypothetical PublicInterface(T) mixin which could dispatch function calls with opDispatch and public data access with its own properties. But that's limiting. I haven't completely thought it over yet, and am open for suggestions :)
Why can't @safe be used, can you use @trusted instead?
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?
You should probably use template constraints for "createUnique" as well.
In my opinion, static assert allows for nicer error messages.
As for coding style, especially if you're aiming for including in Phobos:
If only in some distant future :)
* Function names never start with underscore and always starts with a lowercase letter
Oh, yeah, those. Those would go away outside, as private members of a module :)
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 would prefer the same for instance variables as well, but I know there are several cases in Phobos where instance variables starts with an underscore
Got it, thanks!
