C++ mutable in D

IGotD- nise at nise.com
Sat Jul 31 13:35:21 UTC 2021


On Saturday, 31 July 2021 at 12:27:28 UTC, Gollan wrote:
>
> I'm really surprised you think it doesn't make much sense. What 
> about:
>
> - Locking a mutex to avoid data races when returning a class 
> member from a const getter function
> - Lazy resource allocation (caching) on first call of a const 
> member function

They way I look at it if you don't want the code alter the 
*memory location* then it must be immutable/const. The way you 
describe it, it is based on what the API expect to do with the 
object even if there might be internal memory writes, like the 
semaphore example.

With structures where members are expanded into the structure, 
then they share the memory location and partial const in my 
opinion should be prohibited. Now this can be different with 
classes as members are allocated independently but I'm sure about 
the practical benefit.

It boils down to what we expect const to represent. I used the 
word ROMable for a reason meaning the allocated memory should not 
alter.


More information about the Digitalmars-d mailing list