"in" no longer "scope" since 2.079.0?

[Schrom, Brian T]

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