What's happening with the `in` storage class

[Atila Neves]

On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
> On 6/8/2018 6:02 PM, Mike Franklin wrote:
>> Should it be deprecated (not necessarily removed) to guide 
>> users towards a more consistent and idiomatic usage of the 
>> language? Also, if there are fewer usages, it will make it 
>> much easier to redefine `in` to something useful in the future.
>
>
> 'in' is supposed to mean 'scope const'. But it was never 
> enforced, meaning that suddenly enforcing it is just going to 
> break code left and right.
>
> So I recommend incrementally replacing it as you see it with 
> 'scope const' and fixing anything that breaks.

My $0.02 is that:

* I've always used `in` knowing it meant `scope const`, that 
`scope` wasn't defined, and that one day it would be, possibly 
changing the meaning of my code.

* Currently one has to pass `-dip1000` to get `scope` to do 
anything. This is opt-in. Any breakages would also be opt-in. I 
don't think breakage considerations are important here.

* As Adam pointed out, code that fails to compile that uses `in` 
_and_ `-dip1000` has about a 99.9999% chance of being buggy 
anyway. Yay for buggy code that no longer compiles!

* If `in` means the same as `const`, then this is yet another 
ugly wart that only exists because of historical reasons, and 
makes D harder to teach, or even to justify. "Yes, but..." isn't 
a good look.

I mean, we can't even currently use `-dip1000` in a unittest 
build since that breaks Phobos.
And searching throught github.com is revealing:

https://github.com/search?q=filename%3Adub.sdl+dip1000
https://github.com/search?q=filename%3Adub.json+dip1000

15 hits in all. I say keep `in` as it is. Anybody who was using 
it should have known they were playing with a bleeding edge 
not-yet-implemented feature anyway.

Atila