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
