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

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

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 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.
>
> https://issues.dlang.org/show_bug.cgi?id=17928
>
> - Jonathan M Davis

Well, here I am, writing "in" everywhere in anticipation of DIP1k )
But I guess "do not break" at this point is indeed more important.
Thanks.

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"?

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

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.

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:
>> > [...]
>>
>> 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.

Well, that's not entirely true - there's a PR: https://github.com/dlang/dmd/pull/8021 and it's not too unlikely that it will be part of the DIP1000 change or maybe get its own transition period. Deprecation it and reintroducing doesn't seem to be super popular.

On Tue, Mar 27, 2018 at 03:27:07AM -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
> 
> 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
> 

FWIW,  this is  very much  my opinion,  but if  I am  understanding this correctly, the difference  between the two prototypes below, that I just happened to  be working on, (assuming they  are equivalent with  the old 'in' behavior)  is the  difference between  D being  really great  and D being 'meh' and not much better than C++ syntax wise.

void copyFrom( in size_t baseIndex, in WFFRecord from, in size_t[] args )

vs.

void copyFrom( scope const size_t baseIndex, scope const WFFRecord from, scope const size_t[] args )*

For me, I think the second is so much worse for two reasons:
    1) The prototype is obfuscated in attribute puke and those extra few
       moments to separate the attributes from the parameters bring back
       memories of C++ and needing to put parameters on their own lines.

    2) It's  approaching the line  length that  just works all  the time
       with whatever editor I'm in.

I really  hope that  a better  solution to 'in'  is found.   I'd greatly prefer breaking code (at compile time) and forcing it to be better code, but my programs are short and easy to update.

Actually,  if  arguments to  functions  were  default "logically  input" meaning that they couldn't be  changed, returned, and the compiler could make smart optimizations and pass by  reference or value, etc that would be way better than needing any annotation at all.  (Also @safe and maybe pure  by  default too,  :)  I'd  rather  opt-in  to the  'this'  context pointers)

* I realize  that scope is redundant  but I'm not going  to remember all
  the specific "rules" about it when I  want to say that the argument is
  an INPUT  and don't  mutate or  allow it to  be be  mutated it  in ANY
  surprising way.


Brian

On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
> it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code.

To be frank, this pisses me off to a ridiculous extent because if it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler would now just be actually telling you the truth.

And many of us have spent years describing what it is supposed to do (it WAS documented in the spec the whole time!) and how to use it properly, so much code using it may actually be totally correct, and keeping the original behavior would actually help adoption of the new rules because more code would be compatible with it!

We need to stop being cowards about compile errors. The compiler actually correctly flagging an error that it skipped before isn't code breakage. That's FIXING broken code by actually drawing attention to the ALREADY EXISTING bug.

On Tue, Mar 27, 2018 at 04:16:15PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
> > it was deemed too dangerous to have in suddenly really mean both scope and const, because it would potentially break a lot of code.
> 
> To be frank, this pisses me off to a ridiculous extent because if it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler would now just be actually telling you the truth.
> 
> And many of us have spent years describing what it is supposed to do (it WAS documented in the spec the whole time!) and how to use it properly, so much code using it may actually be totally correct, and keeping the original behavior would actually help adoption of the new rules because more code would be compatible with it!
> 
> We need to stop being cowards about compile errors. The compiler actually correctly flagging an error that it skipped before isn't code breakage.  That's FIXING broken code by actually drawing attention to the ALREADY EXISTING bug.

+1.  I think our current phobia of breaking existing code is getting a little too far on the side of paranoia.  "Breaking" existing buggy code with a compiler error is a good thing.  It's actually helping users find bugs in the code, and I'm sure any reasonable user would appreciate that!  Certainly, I did when it happened to me in the past.


T

-- 
People say I'm arrogant, and I'm proud of it.