"in" no longer "scope" since 2.079.0?

[Jonathan M Davis]

On Tuesday, March 27, 2018 09:58:11 bauss via Digitalmars-d-learn wrote:
> On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
> > On Tuesday, March 27, 2018 09:15:43 Boris-Barboris via
> >
> > Digitalmars-d-learn wrote:
> >> Hello! Can someone point me to the changelong entry or maybe a
> >> pull request, wich changed the "in" from "scope const" to
> >> "const"? I thought the previous matter of things was pretty
> >> natural, and current "in" is now redundant. Would be glad to
> >> read up on this design decision.
> >>
> >> https://docarchives.dlang.io/v2.078.0/spec/function.html#parameters
> >> https://docarchives.dlang.io/v2.079.0/spec/function.html#parameters>
> > Because scope has mostly done nothing (it only affected
> > delegates), in has effectively been const without scope for its
> > entire existence in D2 in spite of the fact that it was
> > supposed to be the same as const scope. Now that DIP 1000 is
> > being implemented, and scope is actually going to do something
> > for more than just delegates, it was deemed too dangerous to
> > have in suddenly really mean both scope and const, because it
> > would potentially break a lot of code. So, in order to prevent
> > such breakage, in was changed to officially only mean const
> > instead of const scope. So, what it's meant in practice hasn't
> > really changed, but the spec has.
> >
> > https://issues.dlang.org/show_bug.cgi?id=17928
> >
> > - Jonathan M Davis
>
> So now "in" is basically just an alias and serves no real purpose
> or is there a plan to eventually make "in" mean something other
> than just "const"?

There are no plans at this point to change the meaning of in again. It has
been suggested that maybe we could deprecate in and reintroduce it as
meaning const scope later, but nothing has been decided beyond the fact that
in now officially is just const, because too much code would break when
-dip1000 became the normal behavior if in meant const scope.

But the reality of the matter is that in has never served any real purpose.
In theory, it was supposed to mean const scope, but scope has never meant
anything for parameters that weren't delegates, and it was never really
defined as to what scope would mean for anything other than delegates. There
were plenty of assumptions about it made by folks, but the reality is that
scope has never been well-defined. Lots of folks have used in either because
they thought that it would benefit their code once some sort of enforcement
was added to scope for types other than delegates, and plenty of folks have
used in simply because they thought that it went well with out. But it has
always been the case that they would have gotten the same effect by using
const rather than in. Plenty of folks have never understood that, since the
spec was never clear on the matter, but that's how it's always been. So,
really, all that's changed is that the spec now reflects reality.

The only hope of in ever serving any real purpose was if scope were finally
implemented to mean something for non-delegates. That's happening with DIP
1000, but it's happening in 2018, and while Walter might have been willing
to break code that used in or scope incorrectly in 2010, he's a lot less
willing to break code now. So, the fact that it took so long for anything to
happen with scope pretty much guaranteed that in would never really mean
const scope.

The only hope of that changing would involve some sort of deprecation of in,
but there are not currently any plans for such.

- Jonathan M Davis