-preview=in might break code

[Steven Schveighoffer]

On 10/2/20 10:32 AM, Andrei Alexandrescu wrote:
> On 10/2/20 10:08 AM, Steven Schveighoffer wrote:
>> Is there a way to prevent this?
>>
>> import std.stdio;
>> struct S(size_t elems)
>> {
>>      int[elems] data;
>> }
>>
>> void foo(T)(in T constdata, ref T normaldata)
>> {
>>      normaldata.data[0] = 1;
>>      writeln(constdata.data[0]);
>> }
>> void main()
>> {
>>      S!1 smallval;
>>      foo(smallval, smallval);
>>      S!100 largeval;
>>      foo(largeval, largeval);
>> }
>>
>>
>> Compile without -preview=in, it prints:
>>
>> 0
>> 0
>>
>> Compile with -preview=in, it prints:
>>
>> 0
>> 1
> 
> Finally, my "told you so" moment has come! :o)
> 
> https://forum.dlang.org/post/rhmst4$1vmc$1@digitalmars.com

My problem with it isn't necessarily that it uses references in some 
cases vs. copies in others, it's that the decision is arbitrary and 
implementation defined.

Legitimately, you can have code that compiles fine on one compiler and 
breaks subtly on others.

But good to see this was at least discussed. However, I'm not sure the 
result is what should have happened...

Just noticed too, if you want to *force* ref by using in ref, you get 
this message:

Error: attribute ref is redundant with previously-applied in

That is... not good.

I think in should always mean ref. If you want to pass not by ref, use 
const.

-Steve