-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking issue for promoting !
to a type (RFC 1216)
#35121
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
Comments
Huzzah! There's a WIP implementation of this here: https://github.com/canndrew/rust/tree/bang_type_coerced It's current status is: it builds with old-trans and is usable but has a couple of failing tests. Some tests fail due to a bug that causes code like My current roadmap is:
Is there anything that needs to be added to this list? Is it just going to be me working on this? And should this branch be moved onto the main repository? |
@eddyb, @arielb1, @anyone_else: Thoughts on this approach? I'm pretty much up to this stage (sans a couple of failing tests that I'm (very slowly) trying to fix). |
Shouldn't This kind of code is fairly common:
I'd expect
But this is only possible if |
@tomaka There's RFC about it: rust-lang/rfcs#1637 The problem is that if |
Then special-case |
@tomaka As for |
But yes, it might be nice if |
When exactly do we default diverging type variables to
But the first error I get is " I'd like to have a clear idea of exactly why we have this defaulting behaviour and when it's supposed to get invoked. |
That's a very good idea in my opinion. Same for |
The trait Balls: Default {}
impl Balls for () {}
struct Flah;
impl Flah {
fn flah<T: Balls>(&self) -> T {
Default::default()
}
}
fn doit(cond: bool) {
let _ = if cond {
Flah.flah()
} else {
return
};
}
fn main() {
let _ = doit(true);
} Only the type variable created by |
Define "specified". :) The answer is that certain operations, which are not afaik written down anywhere outside the code, require that the type is known at that point. The most common case is field access ( If you make it all the way to the end of the fn, then we run all pending trait selection operations until a steady state is reached. This is the point where defaults (e.g., i32, etc) are applied. This last part is described in the RFC talking about user-specified default type parameters (though that RFC in general needs work). |
Boy, that's an old bug! But yes I'd say my #36038 is a dupe of that (I thought I'd seen it somewhere before). I don't think |
Is it planned for #![feature(never_type)]
fn main() {
let result: Result<_, !> = Ok(1);
match result {
// ^^^^^^ pattern `Err(_)` not covered
Ok(i) => println!("{}", i),
}
} |
@tikue yes, it's one of the bugs listed above. |
Could I get some updates from this? |
The plan, as FCPed here, is to:
Rust 2024 is expected to be released in Q1 2025. We're not sure how long step 3 will take after that. See the draft edition guide chapter for further background here: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html |
Checked, faster than expected |
I have some questions regarding 3).
This is a breaking change isn't it? It looks like it could also produce unsoundness in
Why does it have to wait until widespread 2024 adoption?
How can the fallback change without stabilizing in the first place? And why can't it be stabilized with edition 2024 release? |
Yes, it is a breaking change. Yes it can produce unsoundness in unsafe code, however note that we have a lint such unsoundness which is also reported in deps. No, it does not break Rust's stability guarantees, technically Rust permits inference changes (still, this is not something to take lightly, we are trying to take all imaginable precautions to make sure it's as light change as it can be).
We can just do it. Not sure what to add here.
Language team fears the sudden change will break too many things, as planned, we are providing a grace period for everyone affected to patch their code, while making e2024 have the semantics we want from the start.
If you want to learn more, please read recording of T-lang design meeting about the never type, and then a second discussion of some details. |
@WaffleLapkin Thanks for explaining! In particular, the design meeting recording convinced me this is likely the least bad option. I'm just not sure if the lint is 100% reliable since if it isn't it can be a huge problem. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@Seidko, and others who are interested in reporting bugs: Please open a separate bug if you think there is a bug with the never type implementation. This tracking issue does not say it since it likely precedes its inclusion in other tracking issues, but
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This is an issue for tracking the remaining work involved in stabilizing this type, not for "+1" comments. Those comments do not contribute anything to the progress of this feature. So please keep them out of this issue. @kornelski you know entirely well that the type has not been stabilized, and the code you describe works by accident. |
This is |
It may have been unintentional, but the Changes to the fallback in the 2024 edition changed the situation. It's no longer just a trick for accessing an unstable (unnameable) type, but a necessity for dealing with the type that appears in stable code via type inference in the stable compiler. Currently Bevy needs to implement traits on the The ship has sailed for the type stabilization. Only the literal syntax is not on stable. |
@kornelski the hack was known for many years and it doesn't make the type stable. If you are using the hack, you are knowingly opting out of stability guarantees. There is nothing new about this.
It's not a necessity. You can always return the old behavior by specifying the |
As a procedural question, this issue has finished-final-comment-period, but no disposition? Looks like it's left-over from a previous stabilization, that might be a good idea to clear. Is there an up-to-date list of blockers? The issue description itself seems to have all of its linked issues closed. |
I believe the is no explicit "blocker", but we need to wait: #35121 (comment). |
We're taking the next step toward stabilizing the never type ( |
What is it expected to be stabilised, if at all? |
request by: rust-kr#7 (comment) - 위 issuecomment에서 제시한, 원문에서 추가한 내용 중 사실과 다른 부분을 전부 삭제하였습니다. * never type (`!`)의 안정화 관련: 현재 `!`를 타입으로 지정할 수 있는 Rust 2024가 릴리스된 것으로 해당 에디션이 절대다수가 사용하는 에디션이 된 이후에 `!`의 안정화가 진행된다는 Tracking Issue comment에 의거하여 해당 구문은 전부 삭제합니다. - issuecomment: github.com/rust-lang/rust/issues/35121#issuecomment-2241009577 * FFI에 unsafe in unsafe에 대해서도 추가한 내용이 있었는데 들어냈습니다. 역시 기술 서적은 아무나 쓰는 거 아닌가 봅니다. 이해가 딸리는데 막 추가했다가 결국엔 전부 삭제하네요...
Uh oh!
There was an error while loading. Please reload this page.
Tracking issue for rust-lang/rfcs#1216, which promotes
!
to a type.About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Pending issues to resolve
()
without fallback, never type introduces regressions #67225never_type
(!
) #65992Interesting events and links
!
type #35162!
in Rust 1.41.0 #65355Latest Status
#35121 (comment):
Switching the FCWs to lint in dependencies:
The text was updated successfully, but these errors were encountered: