On Friday, 17 January 2014 at 20:06:08 UTC, Jacob Carlborg wrote:

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.

Ahem. Wasn't it what I said? :) Of course I did try. My concern is that it would stop accepting arbitrary user types. Most times this would be a good thing. But not always. Hence I'm hesitating :)

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).

Hmm... That's an interesting notice, I'd need to investigate. Thank you.

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 ;)

Oh, I didn't say so, but of course once they're out of class, they're bound to have proper names. I don't know if you've caught that comment in the code, but I basically intentionally named them ugly to minimize collisions.

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:


Heh, now I'm even more leaning towards a proxy. Because honestly, x.opDispatch!("release")() is even uglier than x.opDot().release() :D By proxy I mean replacing opDot() with a mixin that would directly inject a Unique with an interface of a wrapped object. That has some problems (like how to forward calls to template functions), but hey, I'm experimenting here!

It also occured to me that with alias this you could do something like (cast(X)x).release()... which may or may not do what one expects, and that (in case of both opDot() and alias this) would depend on what exactly do those return (a copy, a reference, etc.).

Reply via email to