-preview=in might break code

[Walter Bright]

On 10/5/2020 12:56 AM, Iain Buclaw wrote:
> Actually, I think there is zero mention of aliasing in the language spec, so the 
> following can only be interpreted as being valid and precisely defined to work 
> in D.
> ---
> float f = 1.0;
> bool *bptr = cast(bool*)&f;
> bptr[2] = false;
> assert(f == 0.5);
> ---

@safe code won't allow such a cast. In @system code, the result will depend on 
the layout of the memory, more specifically big/little endianness. I think we 
can agree that the `in` semantics cannot be restricted to @system code only.


> If this gets addressed, then we can use aliasing rules as a measure for how we 
> treat -preview=in.  If you are interested in defining some aliasing rules for D, 
> I'd be more than happy to spin off a new thread to discuss them, and I will 
> implement that in GDC and report back the success/failures of applying such 
> rules. :-)

The plan for aliasing rules is @live.


> Correct me if I'm wrong, but it looks like we'll have three competing 
> implementations:
> 
> DMD: `const scope`, with `ref` applied on types usually passed in memory.
> LDC: `const scope ref @restrict`
> GDC: `const scope` with `ref` applied on types usually passed by invisible 
> reference.

The problems come from:

1. the user not knowing if `in` is passing by ref or not

2. being "implementation defined" meaning that the user simply cannot know (1) 
because it can change from version to version, or with changes in compiler 
switch settings. Not just in switching from one compiler to another (although 
that's bad enough)

3. the user would have to look at the disassembly to determine (1) or not, and 
this is unreasonable

4. if the function is a template with `in T t` as a parameter, the user cannot 
know if `t` is passed by ref or not