-preview=in might break code

[Walter Bright]

On 10/5/2020 4:52 AM, Iain Buclaw wrote:
> I think we can all agree that the wording needs to be improved.
> 
> Regarding the last sentence (If the type does not fall in one of those 
> categories...), if there's no explicit saying so, I take that to mean do nothing 
> unless you can guarantee that there'd be no change in program behaviour.  Which 
> may as well be as good as being equal to do nothing.
> 
> There's no advantage to passing the remaining types not explicitly named in the 
> spec using ref semantics anyway.  "In" parameters could be forced in memory, but 
> again with a dubious benefit of doing so.

POD types that "wrap" a basic type need to work in the ABI like the basic type. 
An obvious example is using:

     struct Array { size_t length; void* ptr; }

to match dynamic arrays. Another is:

     T, struct S { T t; }, T[1]

should all pass the same way.