Friends don't let friends use inout with scope and -dip1000

[Steven Schveighoffer]

On 8/22/18 4:17 AM, Kagamin wrote:
> On Tuesday, 21 August 2018 at 14:04:15 UTC, Steven Schveighoffer wrote:
>> I would guess it's no different than other inferred attributes. I 
>> would also guess that it only gets promoted to a return parameter if 
>> it's actually returned.
> 
> If we can't have properly typed parameters, it feels like it has 
> potential to prevent some patterns.

But scope is not part of the type, nor is return. One of my biggest 
concerns about dip1000 is that the "scope-ness" or "return-ness" of a 
variable is hidden from the type system. It's just the compiler doing 
flow analysis and throwing you an error when it can't work the thing 
out. I'm more worried about not being able to express the flow in a way 
that the compiler understands, and having it complain about things that 
are actually safe.

> 
> This prevents automatic scope promotion:
> 
> template escape(T)
> {
>      int[] escape1(scope int[] r)
>      {
>          return r;
>      }
>      alias escape=escape1;
> }

But that's not valid dip1000 code. If you call it, it should give a 
compiler error (r *does* escape its scope).

-Steve