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

Regan Heath regan at netmail.co.nz
Thu May 16 04:16:46 PDT 2013


On Thu, 16 May 2013 12:06:18 +0100, Dicebot <m.strashun at gmail.com> wrote:

> On Thursday, 16 May 2013 at 10:41:51 UTC, Regan Heath wrote:
>> 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)
>
> You see, if it is not enforced, than no one has any real responsibility.  
> Multi-threading based on convention has been used quite a lot in C/C++  
> according to my experience it sucks. D developers has done a lot of work  
> in pursuing type system that is aware of multi-threading and can make  
> certain enforcements / provide guarantees. It makes no sense to stop in  
> the midway.

You're missing my main point.

The number of actually "broken" cases are small and the solution is always  
always always to protect the shared data.  assumeUnique cannot help in  
these cases, so the caller ends up calling idup.  The caller cannot safely  
call idup unless the shared data is protected.  So, all roads lead to -  
protect the shared data.  Given that, const(char) is 100% perfectly safe.

> One of D slogans I remember was "Safe by default, efficient when  
> needed". This is exactly one of such cases. Any type contract should be  
> stated explicitly. Everywhere.

As shown above, just using immutable(char) does not ensure it is safe.   
The caller could use assumeUnique mistakenly, or call idup without  
protecting the shared state, both are subtle bugs and the only solution is  
- protect the shared data.

Any impression of complete safety from immutable(char) is therefore false.

R

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


More information about the Digitalmars-d-announce mailing list