What's happening with the `in` storage class

[Jonathan M Davis]

On Friday, June 08, 2018 22:00:02 Ali Çehreli via Digitalmars-d wrote:
> On 06/08/2018 09:55 PM, Walter Bright wrote:
> > On 6/8/2018 7:17 PM, Adam D. Ruppe wrote:
> >> On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
> >>> But it was never enforced, meaning that suddenly enforcing it is just
> >>> going to break code left and right.
> >>
> >> It isn't going to break anything. It is going to *correctly diagnose
> >> already broken code*.
> >
> > Not unless the caller was relying on it being 'in'.
>
> It's been clear since I've heard first about it that it meant 'scope
> const'.

Yes, but the exact mening of scope has never been clear. Plenty of folks
have made assumptions about what it meant, but it was never actually
defined. Now that it is defined with DIP 1000, it seems like pretty much
everyone trying to use it has a hard time understanding it at first (at
least beyond the really simple cases). So, I think that the odds that in is
going to have been used correctly in general are not great. The other issue
is that many folks seem to use in simply because they like the idea that
it's the opposite of out, or they saw others use it and thus decided to
used. While plenty of folks have understood it to mean const scope, a
surprisingly large number of folks seem to have not understood that, and
their code will break if in actually means const scope with -dip1000.

Now, -dip1000 is already going to be breaking code in a number of cases even
without considering the name mangling issues (e.g. auto will end up now
being inferred as scope in some cases). So, it could be argued that it's
going to break code anyway, and thus we might as well just let code that
uses in break if it doesn't actually work with scope, but I think that it's
pretty clear that far more code will break if in really means const scope
than if it stays as const.

An alternative would be to add some kind of deprecation warning that
indicates that in is going to become const scope and that that particular
piece of code will break once it does, but since it can't be both scope and
not scope at the same time, I expect that anyone making such code work with
scope would be forced to change in to const scope anyway, since if they
don't, the changes to make it work with scope wouldn't work until in
actually meant scope.

- Jonathan M Davis