Bug 18604 – in parameter storage class should be deprecated

`in` currently just means `const` even though it was supposed to mean `scope const`. This makes it redundant and confusing and should be deprecated. Maybe after it has been deprecated and been an error for one version, it can be re-introduced with the proper meaning, but for now it should definitely trigger a deprecation warning. > Walter: I don't think we can fix in. It may break an astonishing amount of code, since it was never enforced. See also: https://github.com/dlang/druntime/pull/2139#issuecomment-372455730 https://dlang.org/spec/function.html#parameters

It never should have been changed from `scope const` in the first place. Anyone who was misusing it is responsible for their own mistake - all written material on the language, from spec to tutorials to books, have been clear from the beginning about what it does and when you are supposed to use it. Their code was already broken.

(In reply to Seb from comment #0) > `in` currently just means `const` That antifeature was only sort of done for safe code, whatever you do, system code shouldn't be affected. Though given how much breakage safe code received lately, I see no reason to not enforce scope for `in` in dip1000 mode, I don't think it can add noticeably more breakage, but postponing it will aggravate the issue.

Also the reason why safe code receives breakage is because it's invalid, and there should be no guarantee for invalid code to work.

If one wants to remove `in` attribute the fix is rather simple 's/in/const/'

Personally, I don't think that the in keyword on parameters should ever have existed. Having a keyword essentially be an alias for another keyword just creates confusion, and having it be an alias for _two_ keywords is even worse. If someone means const, they should say const. If they mean const scope, they should say const scope. Given the questions asked and discussions had over the years, I think that it's fairly clear that there are plenty of folks who have never understood what the deal with in is and how it relates to const. The fact that it meant two keywords in principle and one in practice just made it worse. That being said, so many folks liked the idea of in (I think mainly because they conceptually like the idea of it being the counterpoint to out) that a _lot_ of code uses in, and as such, if it were deprecated, a _lot_ of code would have to be changed. So while ideally, I would love to see in deprecated, in practice, I think that it would just break too much code to make sense, as much as that sucks.

Another possibility is -transition=in flag that will deprecate `in` on demand, and after people remove usage of `in` storage class from their code, it can start enforce `scope const` meaning.

`in` has been restored to be `scope const`, albeit with a flag, so WONTFIX.