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
