-preview=in might break code

[Paul Backus]

On Saturday, 3 October 2020 at 14:48:48 UTC, Adam D. Ruppe wrote:
> On Saturday, 3 October 2020 at 14:10:34 UTC, Steven 
> Schveighoffer wrote:
>> What happens is, I write code that assumes some `in` parameter 
>> won't change
>
> That code is kinda already buggy since in just means you won't 
> change it, but somebody else might.
>
> I know it is weird when looking at something that is typically 
> a value copy, but in is still based on const, not immutable, so 
> you must keep some expectation that it might be changed by 
> someone else. (BTW speaking of ref optimizations, any immutable 
> could prolly be passed by reference implicitly as well.....)
>
> But maybe like you said later, the spec should say any `in` is 
> treated at the language level as a `ref` (except for rvalue 
> issues of course) just optimized to value in defined ABI 
> places. That'd probably be good enough.

The real problem here is that existing code, which was developed 
and tested under one set of assumptions, will now have those 
assumptions silently changed underneath it, in a way that is 
impossible to detect until and unless it manifests as a bug. (If 
this sounds familiar to anyone, it may be because it's the same 
issue that @safe-by-default had with extern(C) functions.)

If the decision is ever made to make `-preview=in` the default, 
the existing meaning of `in` should first be deprecated, and 
eventually made into an error.