Extended Type Design: further examples

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Don Clugston wrote:
>>>
>>>> Assuming that 'invariant' = really constant, 'const' = C++ 
>>>> pseudo-const...
>>>
>>>
>>> Yah.
>>>
>>>> It's better than super const. However:
>>>> (1) I would want to go through all my existing D code and change 
>>>> 100% of my usages of 'const' to 'invariant'.
>>>
>>>
>>> Great to hear that!
>>
>>
>> Great perhaps, but it does suggest that 'const' should perhaps be the 
>> signifier for what 'invariant' has been proposed for (the literal 
>> meaning of each term notwithstanding)?
> 
> 
> No. There will be far more uses for const than for invariant. You can 
> take my word for that.
> 
>>>> (2) although (1) could be avoided with the rule that 'const' on a 
>>>> declaration implicitly means 'invariant', this would then mean that 
>>>> to match a 'const' value, you use 'invariant'; but to match a 
>>>> non-const value, you use 'const'. That's horribly confusing.
>>>
>>>
>>> This I don't understand. Could you give an example?
>>
>>
>> invariant int* x;
>> int* y;
>>
>> void fn( const int* z ) {}
>>
>> fn( x );
>> fn( y );
>>
>> Assuming the above is legal, 'const' is the qualifier which binds to 
>> all reference types, ie. "to match a non-const value, you use 'const'."
> 
> 
> That is correct.


How about some further example? Given these sigs:

struct Foo
{
    int a;
}

class Bar
{
    char[] b;
}

void fooish (inout Foo foo) {}

char[] barish (Bar bar) {return bar.b;}


1) how do I modify the function decls to have the compiler *enforce* 
readonly upon the referenced content? e.g. Foo.a and Bar.b cannot be 
mutated within the function body?

2) how does the fooish() decl change to have the compiler *enforce* a 
readonly-view of the returned bar.b?

3) where fooish() has a Foo* rather than an inout Foo, is there any 
change to the modified decl vis-a-vis #1?

- Kris