On Tuesday, 27 March 2018 at 11:24:01 UTC, Jonathan M Davis wrote:
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
Thanks, that explains a lot and makes sense.
