Dicebot on leaving D: It is anarchy driven development in all its glory.

[Jonathan M Davis]

On Wednesday, August 29, 2018 11:15:15 AM MDT H. S. Teoh via Digitalmars-d 
wrote:
> On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via Digitalmars-d 
wrote:
> > On 28.08.2018 19:02, H. S. Teoh wrote:
> > > On Tue, Aug 28, 2018 at 08:18:57AM +0000, Eugene Wissner via
> > > Digitalmars-d wrote: [...]
> > >
> > > > There are still valid use cases where const should be "broken".
> > > > One of them is mutex (another one caching). I have very little
> > > > experiance in multi-threaded programming, but what do you think
> > > > about "mutable" members, despite the object is const?
> > >
> > > The problem with compromising const is that it would invalidate any
> > > guarantees const may have provided.
> >
> > No. You start with the set of allowed program rewrites, then require
> > code with __mutable to not break under them. Code using __mutable is
> > unsafe.
>
> Currently, immutable implicitly converts to const. If const is allowed
> to be overridden, then you could violate immutable, which is UB.

If I understand correctly, the main reason behind looking to add __mutable
is to be able to do stuff with containers that can't currently be done where
you have a way of knowing whether the actual data is truly immutable or not
and thus can avoid mutating data that's actually immutable. That's still
undefined behavior right now, but presumably, if __mutable were added, it
would then be defined behavior that was highly @system and not intended for
normal code. However, even allowing that much does make it so that the
compiler can't then do any optimizations based on const, since while it may
be possible in some cases to avoid mutating immutable data when casting away
const and mutating, I don't see how it would be possible to guarantee that
it would be done in a way that could not possibly be screwed by up
optimizations made at a higher level based on the fact that the objects in
question are typed as const.

Basically, it seems that Andrei really wants a backdoor in const for certain
uses cases, so he's looking to find a way to enable it without really
putting a backdoor in const (IIRC it was discussed as part of this year's
dconf talk talking about the new containers that one of the students is
working on). I guess that he's managed to talk Timon into working on the
issue for him given Timon's excellent knowledge about the type system and
about the related computer science concepts. We'll see what they come up
with, but it's going to be _very_ difficult to make it so that you can
actually rely on const's guarantees if it has any kind of backdoors at all.
However, given some of the technical issues that they've run into with
allocators and containers, Andrei has been rather motivated to change the
status quo. We'll see what happens.

- Jonathan M Davis