DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli

[Regan Heath]

On Thu, 16 May 2013 11:25:48 +0100, Dicebot <m.strashun at gmail.com> wrote:

> On Thursday, 16 May 2013 at 10:13:28 UTC, Regan Heath wrote:
>> ...
>
> I agree that this is a caller responsibility. What leaves me in doubts  
> is how this responsibility is enforced though. With const nothing in  
> type system prevents caller to violate that "contract" and mutate data  
> during function call. Because, well, const does not guarantee that data  
> is not mutated and thus it is a valid action.

True, it's not enforced.  But, that's because the responsibility lies with  
the caller, and I think this is a reasonable position to take in these  
cases (std.file methods which use but do not retain the argument post-call)

> Contrary, immutable is absolutely strict requirement from a function  
> that caller must take care of passed argument during the function call  
> or fall into undefined behavior. Explicit usage of "assumeUnique" by  
> caller is clear sign for a type system "yes, I know what I am doing, I  
> am responsible". And no accidents possible.

Sure, but it's more verbose, and therefore annoying for the general case  
(where the data is not shared).

And..

The issue here is not common (because shared data is not common) /and/  
where shared data is used it should already be protected (because that's  
the existing pattern).

So that leaves us a very small number of cases which are "broken" and the  
solution to all of them is to protect the shared data(*) /not/ to call  
assumeUnique.  The cases where assumeUnique could be used, so could  
const(char).

Basically I think the assumeUnique idea is only useful where const(char)  
is useful and const(char) is far nicer.

(*) you cannot even just call idup, because what if the data is in the  
process of mutating when you do?  You have to protect the shared data with  
a mutex or similar.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/