"in" no longer "scope" since 2.079.0?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Tue Mar 27 19:05:51 UTC 2018


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



More information about the Digitalmars-d-learn mailing list