On Friday, 17 January 2014 at 20:06:08 UTC, Jacob Carlborg wrote:
Unique would fail to compile with those ("failed semantic
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
Hmm... That's an interesting notice, I'd need to investigate.
Oh, yeah, those. Those would go away outside, as private
members of a
Doesn't matter, private could should look just as good as
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
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,