const challenge

[Kris]

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote ...

> 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


Check


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


If implicit, as you say, the sugar would be redundant. On the other hand, 
explicit casting all over the place would be a major step backwards



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


only because 'in' actually appears to do what it implies, whilst apparently 
accepting mutable, const, or invariant. Not to mention it is a darn sight 
more readable than the decorative alternatives.

BTW: how would one pass an invariant string as a const(char[]) argument, per 
the above example? Isn't there a cast required?

Also, who said anything about being in the same thread? All I'm concerned 
with here is the semantics of the callee, and what can be passed to it 
without casts all over the place



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


Are you quite certain of that?



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


the discrete type for slices in D2 does not interfere with this?