-preview=in might break code

[Ola Fosheim Grøstad]

On Sunday, 4 October 2020 at 14:58:13 UTC, Iain Buclaw wrote:
> As it is an optimization, I think that's best left to the 
> interpretation of the compiler/compiler author, however 
> optimizations should never break the semantic guarantee.

What is the intended semantic guarantee in simple words that 
makes sense to an end user?

 From what you say I assume it is something along the lines of:

«Has const scope semantics. Values may be passed as references. 
Parameter passing will not trigger sideeffects on the actual or 
formal parameters.»

However, do you also have this constraint:

«The caller is responsible for ensuring that the actual parameter 
does not alias with other parameters or globals available to the 
called function.»

And if not, what do you have?


The language spec is way too convoluted. This is C++ level of 
convolutedness:

«The parameter is an input to the function. Input parameters 
behaves as if they have the const scope storage classes. Input 
parameters may be passed by reference by the compiler. Unlike ref 
parameters, in parameters can bind to both lvalues and rvalues 
(such as literals). Types that would trigger a side effect if 
passed by value (such as types with postblit, copy constructor, 
or destructor), and types which cannot be copied, e.g. if their 
copy constructor is marked as @disable, will always be passed by 
reference. Dynamic arrays, classes, associative arrays, function 
pointers, and delegates will always be passed by value, to allow 
for covariance. If the type of the parameter does not fall in one 
of those categories, whether or not it is passed by reference is 
implementation defined, and the backend is free to choose the 
method that will best fit the ABI of the platform.»

Stuff like this ought to be an implementors note in an appendix.