On Saturday, 21 May 2016 at 00:39:21 UTC, Jonathan M Davis wrote:
Well, if you actually tried marking functions with pure, you'd
see pretty fast that this won't work with pure. A function
that's marked with pure cannot access any global, mutable
state. It can only access what's passed to it (though in the
case of a member function, that includes the this
pointer/reference). So, your refCountPool will not be
accessible from any pure functions.
Well, I do not have much experience with @pure in D. But I
believe that as far as I'm not using refCounter-modifying methods
of sharedPtr (constructors, assignement, destructor) it should
work. Maybe I'll try it in some future.
You can think of pure as @noglobal, because it can't access
global variables (unless they're constants). That's it's only
restriction, but it's enough to make it so that the only way
that you'd have a backdoor out of const in a pure, const member
function is if you passed a mutable reference to the object as
one of the function arguments.
At this point, if you want ref-counting, you give up on const.
They simply do not go together. The same goes for stuff like
caching or lazy initialization.
Sure, you can get around const to some extent by giving up on
pure, but that only works because you're putting the state of
the object outside of the object itself, which is usally a bad
idea. It also makes it so that const seems like a lie, since
the state of the object isn't really const, since it's not
actually in the object.
I didn't tried the proposed solution, but if this is only
ideological problem and not a technical one, I would be good with
such a solution. On one side the memory reachable from object
isn't modified on the other side the object feels like a const
for the end-used. I mean I miss a logical const from C++ : ).
The standard library already has std.typecons.RefCounted, if
you want to ref-count anything other than classes, but it
really doesn't work with const and fundamentally can't. In
order to have const ref-counting, we're going to need language
support. D does not and likely will never have any form of
"logical" const. If it's const, it's const. Either that fits
with what you're doing, and you can use const, or it doesn't,
and you can't.
I'm currently doing that, but std.typecons.RefCounted is
uncomfortable to use. Probably for reasons mentioned above.
