Destructors, const structs, and opEquals

Don nospam at nospam.com
Tue Dec 14 03:28:49 PST 2010


Jesse Phillips wrote:
> Don Wrote:
> 
>> I can't really escape the feeling that 'const' guarantees too little.
>> It makes guarantees to the caller, but tells the callee *nothing*.
> 
> But it tells the callee exactly what it does, (assuming you unintuitive associate that const objects can be modified). 

It says, "you are not allowed to modify this". But it doesn't tell you 
what it is. Is it immutable? Is it an rvalue? If I write to another 
variable, will this one change? Will the caller call the destructor for 
this parameter?
You don't know any of these things. Yet, the point of the thread is that 
   sometimes you want to know.

But interestingly, if the function is (weakly) pure and has no mutable 
ref parameters, any const parameter could safely be passed by reference.

OTOH one problem I see with 'auto ref' is that it encourages the callee 
to think that a const parameter won't change during the function.

foo(auto ref const X x, ref Y y)
// makes it explicit that modifying y might change x.

foo(const ref X x, ref Y y)
// Modifying y might change x.

foo(const X x, ref Y y)
// If I modify y, will x change?
It can, if x contains a reference type.

AFICT, allowing rvalues to implicitly convert to 'const ref' 
exaccerbates an existing problem, rather than actually creating the problem.



> To me const is nothing but a middle man. It allows you to call functions with both immutable and mutable object types. Which is only similar to @trusted and similar in goals as templates or even 'auto ref'

It would be nice if const meant "this value is immutable for the 
duration of this function call". But I don't think that's possible 
without expensive deep copying.

> 
>> BTW the really big problem I have with 'auto ref' is that it isn't 
>> 'auto', and it isn't 'ref'. I wouldn't have the same objection to 
>> something like 'autoref'.
> 
> I agree here. Makes it seem like you should also have 'auto immutable' and the likes. Maybe there would be reason to look at how we can consolidate all of this. But personally I am not familiar with the problems.


More information about the Digitalmars-d mailing list