"in" no longer "scope" since 2.079.0?

[bauss]

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.