const challenge

[Steven Schveighoffer]

"Kris" wrote
> Steve - some D2 questions for ya:
>
> # char[] other (const(char)[] input, char[] output = null);
> #
> # auto result = other (niftyStringFunction(x, y));
>
> no nesting/chaining of results permitted? That would be a problem :)

This would compile.  Remember, mutable arrays are implicitly castable to 
const arrays :)

>
> I find the current const approach to exhibit various opposing tensions, so 
> I'm not exactly a 'fan' at this time. Taking an example related to the 
> discussion, and if I understand correctly, the variations on Unique!(T) 
> are little more than attempts to hide a cast() operation under a sugary 
> coating, right? A need for such sugar in the language syntax would surely 
> tend to indicate a notable flaw?

I believe the current approach is workable save 2 things:

1. There should be a way to have head-const classes, where the reference 
itself is mutable, but the class data is not

2. There should be a way to specify that a return value is mutable, but can 
be implicitly cast to an invariant (i.e. the unique(X) syntax Janice 
proposed).

>
> 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.

>
> If that's the case, then ok.
>
> Assuming all is kosher so far, sliced 'in' arguments should also be 
> accepted in the same fashion:
>
> # auto result = other ("foo"[0..2]);
>

if you replace in with const, then yes.

> right?
>
> 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.

-Steve