V2 string

Sean Kelly sean at f4.ca
Thu Jul 5 08:45:11 PDT 2007


Derek Parnell wrote:
> On Thu, 05 Jul 2007 00:15:41 -0700, Sean Kelly wrote:
> 
>> Derek Parnell wrote:
>>> I'm converting Bud to compile using V2 and so far its been a very hard
>>> thing to do. I'm finding that I'm now having to use '.dup' and '.idup' all
>>> over the place, which is exactly what I thought would happen. Bud does a
>>> lot of text manipulation so having 'string' as invariant means that calls
>>> to functions that return string need to often be .dup'ed because I need to
>>> assign the result to a malleable variable. 
>> So just use char[] instead of 'string'.  I don't plan to use the aliases 
>> much either.
> 
> It's not so clear cut. Firstly, a lot of phobos routines now return
> 'string' results and expect 'string' inputs.

I'd argue that the parameters should be "const char[]" rather than 
"string", and it's hard to say for the return values.

 > Secondly, I like the idea of
> general purpose functions returning 'const' data, because it helps guard
> against inadvertent modifications by the calling routines. It is up to the
> calling function to explicitly decide if it is going to modify returned
> stuff or not.
> 
> For example, if I know that I'll not need to modify the 'fullpath' then I
> might do this ...
> 
>    string fullpath;
> 
>    fullpath = CanonicalPath(shortname);

I would say that whether the return value is const/invariant indicates 
ownership.  If the called function/class owns the data then it is const 
or invariant.  If it does not then it is not const/invariant.  This 
seems to largely limit "string" as a return value to property methods.

> However, if I might need to update it ...
> 
>    char[] fullpath;
> 
>    fullpath = CanonicalPath(shortname).dup;
>    version(Windows)
>    {
>       setLowerCase(fullpath);
>    }
> 
> The point is that the 'CanonicalPath' function hasn't got a clue what the
> calling function is intending to do with the result so it is trying to be
> responsible by guarding it against mistakes by the caller.

Right.  See above.


Sean



More information about the Digitalmars-d mailing list