phobos
phobos copied to clipboard
Issue 22383 is solved so now can use noreturn
However, this is still draft because the compiler ICEd when testing
Thanks for your pull request and interest in making D better, @dukc! We are looking forward to reviewing it, and you should be hearing from a maintainer soon. Please verify that your PR follows this checklist:
- My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
- My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
- I have provided a detailed rationale explaining my changes
- New or modified functions have Ddoc comments (with
Params:
andReturns:
)
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 references
Auto-close | Bugzilla | Severity | Description |
---|---|---|---|
✗ | 22383 | normal | Array of bottom types not recognized as a range |
Testing this PR locally
If you don't have a local development environment setup, you can use Digger to test this PR:
dub run digger -- build "master + phobos#8283"
Cause for ICE: https://issues.dlang.org/show_bug.cgi?id=22390
What's the motivation for this? Does this enable any specific usage that the previous version didn't? If so, the PR should include a unit test for that usage.
Some (possible) minor advantages(?):
- Removes a redundant custom type
-
only()
can be used to initialize other types that accept a slice -
front
and friends becomenoreturn
as well, diagnosing some misuse (but that's really hypothetical)
only() can be used to initialize other types that accept a slice
Isn't the entire point of using Voldemort types to prevent users from relying on the concrete types of ranges? The only guarantee only
currently makes about its return value is that it is "A RandomAccessRange
" [1]. If someone wants to initialize a slice with only()
, they should be using only().array
.
Regardless, if this is intended to be a supported use-case, there should be a unit test for it.
[1] https://dlang.org/phobos/std_range.html#only
True, relying on that behavior would be problematic when only
is used in variadic templates
only()
should not be relied on being an array, that's an implementation detail. It recently was a private type, i just recently replaced it with a slice in name of simplification. Perhaps unwise, considering that a slice is also bigger than an empty struct. Pr was #8269 - shall we revert?
But there is one useful property with noreturn
elements: they will convert to anything. This enables stuff like float[] arr = chain(only(1,2,3), only(1.1, 2.2, 3.3), only()).array;
. I'll add an unit test but not today. The ICE needs to be solved before testing anyway.
I'd say it's fine to use a noreturn[]
as an implementation detail if it's the simplest way to support the desired use-cases, but the return type should still be auto
and documented only as "a random-access range."
@dukc I am going to close this as the implementation of noreturn is still half baked. We can come back to this later.
@dukc I am going to close this as the implementation of noreturn is still half baked. We can come back to this later.
Okay
Seems strange to close this outright. Why not label as "blocked" if it's only being held back by compiler issues?
@pbackus I did not see the point in having this PR in the queue while noreturn
is still semi-implemented. However, indeed, we can keep it open and label it as blocked.
Issue 22390 has been fixed. Let's give this another spin.
Tried to get this to compile. You guessed it: 1-3 more ICEs dug up from this rabbit hole. Here: https://issues.dlang.org/show_bug.cgi?id=23331
I close this for now. This PR has resulted in three different bug reports already, two of them ICEs. When this PR compiles and passes the tests after enought ICEs are solved, it's still likely that some client code that happens to use empty only()
in a different way than our test will ICE after a compiler update.