--- Comment #11 from Steven Schveighoffer <> 2012-02-03 
03:24:52 PST ---
(In reply to comment #10)
> For example, this should type check:
> immutable(int)[] arr = [2,3,4];
> inout(const(int))[] foo(inout(int)[] x){
>     return uniform(0,2) ? arr : x;
> }
> inout(int)[] id(inout(int)[] x){
>     return x;
> }
> inout(int)[] bar(inout(int)[] x){
>     inout(int)[] y = [1,2,3];
>     inout(const(int))[] z = id(foo(y)); // inout const substitute for inout
>     return z~x;
> }

This typechecks even if we don't have inout(const) as an option:
  inout matches inout (we need a new term for this 'local' inout!)
  foo(y) => inout(int)[]
  inout(int)[] => inout(const(int))[] => z

Besides, you are assuming here that the lvalue side of the expression plays a
role in determining the inout match.  It doesn't.  The return type is solely
determined by the argument expressions.

> There are indeed corner cases, for example:
> void foo(immutable(int) x, float y){}
> void foo(const(int) x, float y){}
> void foo(int x, float y){}
> void main(){foo(1,1);} // error, matches all three

This case has no relevance, there is no inout return value.  Who cares what
inout resolves to?

Not to be nit picky, but we should consider that any polysemous value type is
not going to play a vital role in an inout function, since it's implicitly
convertible to any modifier.  It's references or contained references which
make a difference.

If it comes down to supporting this, choosing any inout match arbitrarily is
good enough.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to