Bug 17928 – [scope] `in` is not treated as `const scope`

This behavior is contrary to the documented specs and also does not match how almost the whole community uses `in`. https://dlang.org/spec/function.html#parameters

I am reluctant to change the behavior of `in` until we're satisfied how `scope` should behave.

Personally, I think that it was a mistake to create a storage class which was equivalent to two other storage classes, but clearly, a number of folks like the idea. I suspect that a lot of folks use in simply because it looks like the opposite of out and don't really understand what it's supposed to do. And out of those who do understand what it's supposed to mean, there's a high change that they've misused it, because it was never checked. Also, while the basic idea of scope is simple enough, what it actually means in practice was never defined, increasing the chances that it was misued. If we want in to mean scope const instead of just const, then we're going to need a means of migrating to that without immediately breaking code - but we're arguably going to need that with scope in general, because any place that it was used aside from delegates has been a no-op, and once DIP 1000 is enabled as the default, at least some of that code will break. So, we need a plan in general of how to migrate towards DIP 1000 being the default behavior once it's ready. And I don't see any reason why in's behavior can't be changed as part of that just like scope's would be, since changing the behavior of either is a breaking change.

(In reply to Jonathan M Davis from comment #2) > Personally, I think that it was a mistake to create a storage class which > was equivalent to two other storage classes, but clearly, a number of folks > like the idea. scope const is very common, so shorthand is useful. > I suspect that a lot of folks use in simply because it looks like the > opposite of out and don't really understand what it's supposed to do. I don't think it's the case, because compiler already performed optimizations based on meaning of scope. The problem is that scope was used in a way that can't be checked by the compiler.

Commit pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/71ad1b38d5b5d0a25e383c1dce27e90ed6698f71 Parameter storage class in is an equivalent of const currently; see also discussion in issue #17928; may change later to const scope

My take on that is to describe the current dmd behavior in the spec: I think it's less confusing to possibly change the spec later again, than currently being confused about, that dmd behaves different from the spec. I well remember Scott Meyer's comment at DConf 2017 referring importance of compiler/spec consistency and absolutely agree. I submitted PR https://github.com/dlang/dlang.org/pull/2126

Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/37a41f508b24f5dbb780ab37b28409453edd7c9e std.uni: Replace parameter storage class in by what it should express (const scope, but dmd treats it as const); see also merged dlang.org PR #2126 or issue #17928

(In reply to Carsten Blüggel from comment #5) > I submitted PR https://github.com/dlang/dlang.org/pull/2126 It only applies to @safe code and dip1000 as a fix to safety checks, @system still has old behavior as it's not affected by safety checks.

Implemented in https://github.com/dlang/dmd/pull/10769