Issue 22383 is solved so now can use noreturn

[dukc]

However, this is still draft because the compiler ICEd when testing

[dlang-bot]

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: and Returns:)

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"

[dukc]

Cause for ICE: https://issues.dlang.org/show_bug.cgi?id=22390

[pbackus]

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.

[MoonlightSentinel]

Some (possible) minor advantages(?):

1. Removes a redundant custom type
2. only() can be used to initialize other types that accept a slice
3. front and friends become noreturn as well, diagnosing some misuse (but that's really hypothetical)

[pbackus]

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

[MoonlightSentinel]

True, relying on that behavior would be problematic when only is used in variadic templates

[dukc]

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.

[pbackus]

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."

[RazvanN7]

@dukc I am going to close this as the implementation of noreturn is still half baked. We can come back to this later.

[dukc]

@dukc I am going to close this as the implementation of noreturn is still half baked. We can come back to this later.

Okay

[pbackus]

Seems strange to close this outright. Why not label as "blocked" if it's only being held back by compiler issues?

[RazvanN7]

@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.

[RazvanN7]

Issue 22390 has been fixed. Let's give this another spin.

[dukc]

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

[dukc]

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.