-preview=in might break code

[Walter Bright]

On 10/4/2020 7:34 PM, kinke wrote:
> 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.

I do understand what it is for.

>> 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.

Static analysis, especially when it is part of the language (not an add-on) is 
vastly superior to runtime checking. (Runtime checking, such as array bounds 
overflow checks, can never prove an overflow is not possible. Static analysis can.)

So yes, I very much am focused on static analysis.


> 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.

See my upcoming talk at #dconf2020 !