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

[Jonathan M Davis]

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