March 27, 2018 Re: "in" no longer "scope" since 2.079.0? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 |
March 28, 2018 Re: "in" no longer "scope" since 2.079.0? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bauss | 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.
|
Copyright © 1999-2021 by the D Language Foundation