-preview=in might break code

[Iain Buclaw]

On Monday, 5 October 2020 at 02:46:42 UTC, Andrei Alexandrescu 
wrote:
> On 10/4/20 10:19 AM, Iain Buclaw wrote:
>> On Saturday, 3 October 2020 at 05:02:36 UTC, Andrei 
>> Alexandrescu wrote:
>>> Who approved this? How in the world did a group of competent,
>>> well-intended people, looked at this and said - yep, good 
>>> idea. Let's."
>>>
>>> ???
>>>
>> 
>> *You* approved it.
>> 
>> https://github.com/dlang/dmd/pull/11000#issuecomment-675605193
>
> Oi. Touché.
>

I know the feeling all too well.  I have on a few occasions ran 
into issues in the D front-end (from GDC) and asked "who on Earth 
wrote or approved this?", only to discover that it was Me, two 
months ago. :-)

>>> Please, we really need to put back the toothpaste in the tube 
>>> here. I could on everybody's clear head here to reconsider 
>>> this.
>> 
>> Frankly, I think you are making a mountain out of a molehill 
>> here.  You are imagining a problem that doesn't exist; and if 
>> one does find an issue, the fault lies with the DMD compiler 
>> and not the D language specification.  Though evidently having 
>> clearer wording in the spec benefits all.
>
> I think my STL examples have put the narrative that confusing 
> aliasing is rare to rest.
>

The spec as is currently written does seem to be wide open to 
interpretation.  But I think that trying to reason 'in' in terms 
of 'ref' and 'restrict' semantics should be left at the door.

Any thought-problems that arise from aliasing is hard to justify 
in my view because in practice I just can't see D having strict 
aliasing rules so long as it continues to not be enforced in some 
way.

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);
---
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. :-)

>> If you read nothing more of this reply, at least finish up 
>> until the end of this paragraph.  Please hold fire until GDC 
>> and LDC have implemented this feature, then we can discuss the 
>> pitfalls that we've encountered with it.  Basing decisions on 
>> behaviors observed with DMD is not the right approach, and if 
>> you are currently finding the situation to be a mess, it is a 
>> mess of DMD's own doing.
>
> Implementation details of dmd are not of concern here, and in 
> fact the more different ldc/gdc/dmd are from one another, the 
> more problematic the entire matter is.
>

As this is an experimental feature, a bit of deviation in 
implementations can be seen as a good thing.  Convergence can 
come later once we work out just who has got it right.

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.