Persistent list

[Steven Schveighoffer via Digitalmars-d]

On 11/15/15 9:54 AM, Andrei Alexandrescu wrote:
> On 11/15/2015 09:34 AM, Dicebot wrote:
>> On Sunday, 15 November 2015 at 14:23:05 UTC, Jonathan M Davis wrote:
>>>> As I mentioned, he's okay with changing the language to make the
>>>> casts well defined. -- Andrei
>>>
>>> Well, that's a big change, since it pretty much means that D's const
>>> isn't physical const anymore, and Walter has been _very_ insistent
>>> about that in the past - to the point that he's argued that C++'s
>>> const is outright useless because it isn't physical const. If casting
>>> away const and mutating is well-defined behavior, then we basically
>>> have C++'s const except that it's transitive ...
>>
>> Casting away _const_ is already legal if programmer can himself
>> guarantee underlying object has mutable origin (i.e. not available via
>> immutable reference), by the very definition of const. It is casting
>> away immutable and mutating that is strictly UB.
>
> Correct. I'm not sure whether that's clarified in the language
> documentation yet. -- Andrei

I argued this way, and eventually lost. I don't think it's feasible to 
have a const that can be cast away, and have optimizations based on 
const or pure.

See this discussion:

forum.dlang.org/post/riiehqozpkyluhhifwha at forum.dlang.org

One thing, however, is that if you can mark an island of space within an 
object as ALWAYS mutable, the compiler can know this and avoid 
optimizing away access to those pieces. It would have to be clearly 
marked as such, so the optimizations on non-marked data could still happen.

I think it could be done, because logical const is possible via a global 
lookup table. Any time you go through a cast, however, this could easily 
break down. I hate to say it, but you would likely need another modifier 
like "tainted const" or something in order for that to work.

-Steve