simple definition of "in" function parameters, and default "ref"

[Stanislav Blinov]

On Saturday, 27 October 2018 at 11:48:55 UTC, John Nixon wrote:
> I have just read that the storage class "in" for function 
> parameters has not yet been properly implemented. From its 
> simple meaning as a one-way flow of information into a function 
> from the calling function, surely it should be implemented by 
> copying the argument, as is now done by default for all 
> function arguments.

```
void foo(T)(in T value) { /* ... */ }

int i;
Object o;

// 1
foo(&i);
// 2
foo(o);
```

Are you suggesting that for (1), typeof(value) in foo should be 
`int*`? And that for (2) typeof (value) in foo should be 
`Object`? This can't work. You can't implicitly "copy" a pointee 
or a referree, you can only copy the respective bits of the 
pointer/reference. If you do that and strip `const` from the 
argument, you're left with a non-const pointer or reference, 
respectively, which would make `in` pointless.

 From the spec 
(https://dlang.org/spec/function.html#param-storage):
"[in] defined as scope const. However in has not yet been 
properly implemented so it's current implementation is equivalent 
to const. It is recommended to avoid using in until it is 
properly defined and implemented. Use scope const or const 
explicitly instead."

Translation: a long time ago, `in` was supposed to be a shorthand 
for `const scope`. Later on Walter in his patches started 
treating `in` as just `const`, as doing otherwise would "break 
too much [third-party user] code". Current wording indicates that 
that could've been a mistake.

> It would also make it simpler if there was no difference 
> between the behaviour of reference and value types in function 
> parameters with default passing by reference.

Now that is a catastrophe-breaking-change suggestion if I've ever 
seen one.