const challenge

[Sean Kelly]

Steven Schveighoffer wrote:
> "Kris" wrote
>> As far as the example api-style goes, here's hoping that this will work 
>> correctly in D2:
>>
>> # char[] other (in char[] input, char[] output = null);
>>
>> where 'in' indicates only that the input will not be modified by the 
>> callee. By doing so, the following should be clean:
>>
>> # char[] nested (in char[] input, char[] output = null);
>> #
>> # auto result = nested (other (x, y));
>>
>> Given that the input cannot be modified, you should also be able to pass a 
>> const or invariant string as an 'in' parameter; right?
>>
>> # auto result = other ("foo");
> 
> 'in' isn't necessary in my mind.  How can the callee modify the string if 
> the callee is in the same thread?  I think what you want here is 
> const(char)[] input.  This specifies that the input is not supposed to 
> change.

Doesn't "in char[]" map to "const char[]" in 2.0?

>> Additionally, the optional output should always be good for use with 
>> slices also:
>>
>> # char[32] buf;
>> #
>> # auto result = other ("foo", buf[0..8]);
>>
>> yes?
> 
> Well, as long as other doesn't allocate more data if buf can't hold it :) 
> Then yes, it is fine.

This is one area where I'd like to have head const, as I think it would
eliminate the problems that the "T[new]" change was proposed to address.
 buf[0..8] can't be resized (in place), but its contents should be
modifiable.


Sean