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

[12345swordy]

On Saturday, 27 October 2018 at 13:28:20 UTC, Jonathan M Davis 
wrote:
> On Saturday, October 27, 2018 5:48:55 AM MDT John Nixon via 
> Digitalmars-d 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.
>> Note this has a distinct meaning from the far more restrictive
>> "const" that enforces the variable to remain constant 
>> throughout
>> its lifetime while the called function is running. It would 
>> then
>> naturally complement "out" and provide a simple semantics in 
>> the
>> function signature to aid program design.
>> 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. This would make the storage
>> class "none" correspond to "in" and "out". At present if this 
>> is
>> wanted, sometimes the keyword "ref" has to be used, and 
>> sometimes
>> it is not necessary (depending on whether the type is value or
>> reference).
>> A simplified language would make it easier to develop programs 
>> to
>> check programmer's code.
>
> in was supposed to be identical to const scope. However, scope 
> has never really done much aside for delegates and was not very 
> well defined, so it's pretty much just been the same as const. 
> Lots of people have used it either because they liked the idea 
> that it was the counterpart to out or because they thought that 
> they understood what how it was supposed to work and wanted 
> whatever behavior that was, but it wasn't actually properly 
> defined and has always just been the same as const for 
> everything other than delegates. So, arguably, no one should 
> have been using it, but lots of people have been.
>
> However, DIP 1000 actually defines what scope means and makes 
> it work for more than just delegates, and the result would be 
> that making in actually mean const scope as originally intended 
> would then break a _lot_ of code. _Some_ of that code should be 
> broken, because the author used scope in a way that's close 
> enough to what scope is actually going to mean that the fact 
> that the code doesn't compile would mean that a bug will have 
> been caught, but in the vast majority of cases, in was used 
> without a proper understanding of what it would mean - 
> especially since scope was not properly defined, and as it is, 
> now that scope _does_ have a proper definition with DIP 1000, 
> most people don't understand it very well outside of simple 
> examples, meaning that it's hard to correctly write code that 
> uses scope with -dip1000 even now. So, it's _highly_ unlikely 
> that existing code using in is using it in a way that's going 
> to be compatible with scope. So, the current plan is for in to 
> remain as const rather than to become const scope, because it 
> would mean far less code breakage. Some people are not very 
> happy about that, and the plan may yet change, but either way, 
> there's pretty much no way that in is going to be changed to 
> mean something else entirely at this point. Doing so would 
> break even more code than actually making it mean const scope 
> as originally intended would.
>
> - Jonathan M Davis

The "in" feature perplex me here, I never understand why we 
couldn't simply write "const scope" instead of "in". Seems it 
better off to mean "(foreach var a in x)" for readability sake 
instead of using as a parameter that no-one seems to be hardly 
using.