Am 09.05.2014 00:02, schrieb Timon Gehr:
On 05/08/2014 06:30 PM, Sönke Ludwig wrote:
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole "const" thing moot.
This is not guaranteed to work. I guess the only related thing that is
safe to do is casting away const, but then not modifying the memory.
For what practical reason would that be the case? I know that the spec
states "undefined behavior",
Case closed.
Bonus points for getting the difference between "practical" and
"theoretical"...
I'd rather say that the spec needs clarification there. It explicitly
states the immutable->mutable case, but it at least makes the strong
impression that const->mutable is only left undefined (implicitly,
AFAICS) because a const pointer might point to immutable data.
Anyway, I feel like I'm dragged into an artificial argument here that
has nothing to do either with the original topic, or with what my
original statement was about. I agree that a RefCount struct currently
has more issues than the head/tail/transitivity of const. My statement
on this (off) topic is simply that payload and reference count must be
handled separately WRT to const to make sense (because const(RefCount)
*does* occur in practice) and that it can be practically achieved using
an internal cast now (immutable being a different beast). Nothing more,
nothing less.
