• Boris-Barboris (7/7) Mar 27 2018 Hello! Can someone point me to the changelong entry or maybe a
• Jonathan M Davis (13/20) Mar 27 2018 Because scope has mostly done nothing (it only affected delegates), in h...
• Boris-Barboris (5/14) Mar 27 2018 Well, here I am, writing "in" everywhere in anticipation of DIP1k
• bauss (4/26) Mar 27 2018 So now "in" is basically just an alias and serves no real purpose
• Jonathan M Davis (29/59) Mar 27 2018 There are no plans at this point to change the meaning of in again. It h...
• bauss (2/70) Mar 27 2018 Thanks, that explains a lot and makes sense.
• Seb (6/21) Mar 27 2018 Well, that's not entirely true - there's a PR:
• Kagamin (5/8) Mar 28 2018 At this point it's the spec that serves no real purpose,
• Adam D. Ruppe (14/17) Mar 27 2018 To be frank, this pisses me off to a ridiculous extent because if
• H. S. Teoh (9/27) Mar 27 2018 +1. I think our current phobia of breaking existing code is getting a
• Jonathan M Davis (35/53) Mar 27 2018 All it ever said about scope was that it prevented references from escap...
• Schrom, Brian T (29/44) Mar 27 2018 FWIW, this is very much my opinion, but if I am understanding this

Boris-Barboris <ismailsiege gmail.com> writes:

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

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

Boris-Barboris <ismailsiege gmail.com> writes:

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.

bauss <jj_1337 live.dk> writes:

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

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

bauss <jj_1337 live.dk> writes:

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.

Seb <seb wilzba.ch> writes:

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.

Kagamin <spam here.lot> writes:

On Tuesday, 27 March 2018 at 09:58:11 UTC, bauss 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"?

At this point it's the spec that serves no real purpose, 
sometimes in is scope, sometimes it isn't and sometimes scope is 
not scope either. I don't think any decision was made on this, 
it's just PRs getting merged as long as tests pass.

Adam D. Ruppe <destructionator gmail.com> writes:

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Tuesday, March 27, 2018 16:16:15 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,

All it ever said about scope was that it prevented references from escaping.
It did not explain what that meant for any particular type. Reasonable
assumptions could be made about what it probably meant, but it was never
actually explained. DIP 1000 explains the semantics, and it clearly goes
beyond whatever might have been originally planned, because it applies scope
to far more than just parameters in order to make it work.

 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.

Well, if you want that, you'll have to talk Walter into it. In this case, I
very much agree with him. Based on discussions on it in the past, and many
of the questions that have popped up over the years, I think that it's quite
clear that a lot of folks have been using in without really understanding
it, meaning that I don't think that it's at all safe to say that the average
programmer used in expecting anything like the semantics of DIP 1000, and
the changes that -dip1000 requires means that scope needs to be used in a
lot more places than just the function parameters, meaning that even if the
programmer had meant in / const scope in the way that DIP 1000 means scope,
their code is going to have quite a few compilation errors with the change.
This wouldn't be a few compilation errors here and there that would catch
bugs. This would be compilation errors all over the place because either in
was misused and/or because scope is required in a bunch of extra places to
make it work.

Now, I there are enough issues with using -dip1000 that I don't know how
Walter is ever going to make it the default behavior anyway. So, maybe
there's room to argue that it causes enough breakage on its own that it
doesn't matter if in breaks everything, but I think that it's very much a
stretch to argue that most of the uses of in in the wild match what -dip1000
means.

Personally, I think that it was mistake in the first place to have a keyword
be an alias for another keyword - let alone two keywords - but the only way
to fix that would be to deprecate in, and given that Walter's reaction was
to make in const rather than deprecate it, I question that he could be
talked into doing so. It _is_ used by a lot of code, whether the programmer
meant anything like DIP 1000 means or not.

- Jonathan M Davis

"Schrom, Brian T" <Brian.Schrom pnnl.gov> writes:

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