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

[Regan Heath]

On Wed, 15 May 2013 18:32:03 +0100, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
> What's less clear is what to do when a function accepts strings but  
> isn't really operating on them (e.g stuff in std.file or std.net.curl),  
> as they may need immutable(char)[]. In that case, it depends on what's  
> being done with the string. For better or worse though, at this point, I  
> think that it's most common to just accept string for those cases. It's  
> not something that always has a clearcut answer though.

I agree with the first bit, but I think we can make a clear-cut decision  
on this last..

To me it comes down to a Q of responsibility.

Should a function/method (like those in std.file) require that the  
argument will not change for the lifetime of the function/method call, or  
is it reasonable for the function/method to assume the caller will ensure  
that.

Taking by immutable(char) will guarantee it will not change (ignoring  
blunt forced cast) whereas const(char) will not, but there is an implicit  
assumption that it wont change and the caller should guarantee that.

So, who's responsibility is it to ensure the function/method call executes  
without errors caused by mutable shared data?

I think it's the callers responsibility and think that const(char) is the  
better choice in cases like this, my reasoning as follows..

1. Callers should already be protecting shared mutable state before using  
it, this is a common and well understood pattern which cannot be avoided  
even if we use immutable(char) arguments (caller still needs to ensure  
shared state is not mutated while they make the immutable copy to pass).

2. In most cases, in most code shared data is less common, especially for  
calls to functions/methods like those mentioned here.  So, we chose the  
option which is nicer for the common case, and const(char) is it.

3. const(char) does not require duplication of arguments by caller or  
callee so is more efficient, one of D's primary goals and a good baseline  
to build upon.

So, I think in cases where the function/method doesn't need to retain the  
argument for longer than the lifetime of the call it should accept  
const(char), otherwise as you mentioned earlier it's better to simply  
require the caller provide the immutable(char) you require.

This decision has a nice side-effect of implicitly documenting the  
lifetime/usage of arguments, const(char) means call lifetime,  
immutable(char) means longer, possibly indefinitely (until termination).

Thoughts?

R

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