-
-
Notifications
You must be signed in to change notification settings - Fork 745
Annotate more of phobos with return
and scope
#8113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + phobos#8113" |
495d4d8
to
a023284
Compare
This should be good to go now: I can now locally build Phobos' unittests with dlang/dmd#12010 I undid some of the scope annotations of Per's PR because they were only done to satisfy the requirement that Many range functions don't have correct |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pardon my ignorance here
For a lazy version, see $(REF joiner, std,algorithm,iteration) | ||
+/ | ||
ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep) | ||
ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, R sep) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this removes scope
I thought this PR was trying to add it, am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Range functions should ideally infer scope
based on empty()
, popFront()
, front()
, copy constructors etc.
scope
inference is not that good yet however (issue 20674) so sometimes scope
is manually applied to help the compiler. With issue 20150 fixed, this scope R sep
gives an error:
scope variable
sep
assigned to non-scope parameterr
calling std.array.array!(Once).array
So the long term fix is to ensure scope
inference works for both join
and array
, but that's an enhancement. For now it's important to get the dip1000 bug fix in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this break existing code if the inference fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the accepts-invalid fixes for dip1000 are breaking changes. Luckily dip1000 is still experimental.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But these changes are neither specific to DIP1000 nor about actually invalid code. It would be better to first improve the inference s.t. there is no unecessary breakage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What code do you think would break without -preview=dip1000
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have aspecific example ATM, will post one if I find a small example.
But we should strive to not break valid code. -dip1000
has existed for quite some time and is certainly used in the wild.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dlang/dmd#12010 is going to break such dip1000 code in the wild undoubtedly, I just tested it on my own 37 KLOC dip1000 library and I had to add 3 scope
annotations. Do you think we need a second switch preview=dip1000fixed
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither said nor implied that - some breakage will be unavoidable. I'm just concerned that these changes introduce a temporary regression that could be avoided by first improving the scope
inference.
But the actual fallout might be neglegible given that your projects required minimal changes and buildkite passes as is.
See_Also: | ||
$(LREF asAbsolutePath) which does not allocate | ||
*/ | ||
string absolutePath(return scope string path, lazy string base = getcwd()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
absoultePath
calls chainPath(baseVar, path).array
, and scope
inference fails for .array
currently
`Exception` if the specified _base directory is not absolute. | ||
*/ | ||
string relativePath(CaseSensitive cs = CaseSensitive.osDefault) | ||
(scope return string path, lazy string base = getcwd()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
relativePath
calls asRelativePath
which takes input ranges, and scope inference fails there
This otherwise looks OK |
Thanks for clearing that all up. |
please rebase or force push to start CircleCI |
9d930b0
to
a94213e
Compare
void move(T)(ref T source, ref T target) | ||
{ | ||
moveImpl(source, target); | ||
moveImpl(target, source); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the reversion of parameter order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably should have made a comment in the source code as well
Continuation of #8076, but for dlang/dmd#12010 instead of dlang/dmd#10924
I'm still figuring out what to do with range functions like
array
,text
andtoCase
.scope
fails to be inferred for simplechar[]
cases, but puttingscope
on them forces every InputRange it's called on to bescope
compatible, while a genericInputRange
can escape its innards through global variables or Exceptions. Not that I want to support such ranges, but it would make transitioning to-dip1000
more diffcult for users, so it may be better to leave them be and use work-arounds for current Phobos functions that need them to bescope
, like I did instd.getopt
by replacingsplit
(notscope
compatible, returns array of slices) withsplitter
(lazy,scope
compatible).