-preview=in might break code

[kinke]

On Monday, 5 October 2020 at 01:59:58 UTC, Walter Bright wrote:
> On 10/4/2020 3:27 PM, kinke wrote:
>> Again, the aliasing issue should be quite easily avoided by 
>> imagining `in` params as `const scope ref` at the call sites.
>
> I'd be fine calling it `const scope ref`. At least it says what 
> it is doing, and its behavior is not implementation defined.

But that's not the whole picture. It's about optimizing small-POD 
cases such as `in float4` - no, I don't want (extremely verbose) 
`const scope ref float4` to dump the argument to stack, pass a 
pointer to it in a GP register, and then have the callee load the 
4 floats from the address in that GP register into an XMM 
register again - I want to pass the argument directly in an XMM 
register. Similar thing for an int - why waste a GP register for 
an address to something that fits into that register directly?
With `-preview=in`, this works beautifully for generic templated 
code too - non-PODs and large PODs are passed by ref, small PODs 
by value, something C++ can only dream of.

> The thing is, I've been working for years on making D as memory 
> safe as we can. This feature is a big step backwards.

But you're solely focusing on static analysis. Static analysis is 
great but quite obviously limited. Runtime sanitizers are a 
necessary supplement, and easy to integrate with LLVM for example 
- adding support for existing language-independent address and 
thread sanitizers for LDC was pretty simple, and excluding tests, 
probably amounted to a few hundred lines, mostly wrt. copying and 
correctly linking against prebuilt libs.

Wrt. aliasing, I think it's more of a general problem, and I 
guess a `const ref` param being mutated while executing that 
function is almost always an unintended bug. -preview=in would 
make that definitely a bug for each `in` param.