Casting away const

[Steven Schveighoffer]

On Mon, 09 Aug 2010 10:37:14 -0400, BCS <none at anon.com> wrote:

> Hello Steven,
>
>> On Mon, 09 Aug 2010 10:11:39 -0400, Don <nospam at nospam.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>
>>>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
>>>> <simen.endsjo at pandavre.com> wrote:
>>>>
>>>>> I'm totally new to the const/immutable thing, so this might be a
>>>>> naive  question..
>>>>>  The spec says:
>>>>> "modification after casting away const" => "undefined behavior"
>>>> I thought it was "you're on your own", not undefined behavior.  The
>>>> former implies there is some "right" way to do this if you know more
>>>> about the data than the compiler, the latter implies that there is
>>>> no
>>>> right way to cast away const.  Am I wrong?
>>>> -Steve
>>> I think you're wrong. It's OK to cast away const, as long as you
>>> don't
>>> modify the thing which is supposed to be const.
>>> But if you modify it, there's no way the compiler can guarantee that
>>> your code will work. Anything could happen.
>>
>> But then what is the point of casting away const?  If you are not
>> going to  modify it, then there is no reason to cast it away.
>
> There are some cases where non-const pointers are used but never  
> modified (C api's for instance) cast as always is just a way subvert the  
> type system where it gets in your way.

C's api can be modified at declaration.  It has no mangling, so you can  
type it how it should be (if C had const).  For example:

extern(C) int strlen(const(char)* str);

I find that much more pleasant than having to cast away const.

-Steve