-preview=in might break code

[Steven Schveighoffer]

On 10/3/20 11:30 AM, Ola Fosheim Grøstad wrote:
> On Saturday, 3 October 2020 at 14:49:03 UTC, Steven Schveighoffer wrote:
>> `in ref` is a reference, and it's OK if we make this not a reference 
>> in practice, because it's const. And code that takes something via `in 
>> ref` can already expect possible changes via other references, but 
>> should be OK if it doesn't change also.
> 
> You either support aliasing or not.
> 
> If you support aliasing then you should be able to write code where 
> aliasing has the expected outcome.
> 
> Let me refer to ADA. According to the ADA manual you can specify that an 
> integer is aliased, that means that it is guaranteed to exist in memory 
> (and not in a register). Then you use 'access' to reference it.
> 
> If a language construct says "ref" I would expect 100% support for 
> aliasing. It is not like aliasing is always undesired.
> 

Given that it's a parameter, and the parameter is const, it can only 
change through another reference. And this means, the function has to 
deal with the possibility that it can change, but ALSO cannot depend on 
or enforce being able to change it on purpose. On that, I think I agree 
with the concept of being able to switch to a value.

What I don't agree with is the idea that one can write code expecting 
something is passed by value, and then have the compiler later switch it 
to a reference. `in` means by value in all code today. The fact that we 
tried -preview=in on a bunch of projects and they "didn't break" is not 
reassuring.

-Steve