From slices to perfect imitators: opByValue

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Thu May 8 16:05:32 PDT 2014


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.


More information about the Digitalmars-d mailing list