-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Hierarchy of Sized traits #3729
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
I guess I just disagree with this. It's a subjective statement anyway. I would appreciate if the RFC could list the syntax as an unresolved question: should there be some clear syntactic marker that the default bound is removed, or are we okay with that being an entirely implicit side-effect of adding another bound? I am not sure if it is necessary to commit to a particular syntax for this already, and seeing this used in practice will help determine how confusing it really is. As one point for why this is confusing, imagine I have trait MyTrait: const ValueSized {} and now I write
👍 , given that all the types we currently have determine their size based on the metadata, not the value, this seems prudent. The name of
So the idea is that
|
I've added this as an unresolved question.
That makes sense. You're right that
I've added this as an unresolved question too.
I've added explicit parentheses to make this clearer for now until a |
Another summary comment! Here are the previous update summaries copied below so you don't need to uncollapse GitHub comments to find it: 2024-11-25Summary comment: #3729 (comment) For those following along or catching up, these are the notable the changes to the RFC since this was posted:
And these are all the other smaller changes that don't materially impact what is being proposed:
At the moment, I prefer the following alternatives to the primary proposal of the RFC, and may re-write to incorporate these as the primary proposal:
These are links to the compare with previous versions of the document (switch to the "Files changed" tab and then the rich diff):
These are the major changes since the last summary: These are the minor changes since the last summary:
These are the alternatives described in the RFC that I think are worth consideration as the primary proposal:
|
Since there seems to be consensus on it, I've adopted the alternative for replacing |
`size_of_val` and `align_of_val` and this remains a blocker for extern types. | ||
|
||
Furthermore, unsized types can only be the final member of structs as their | ||
alignment is unknown and this is necessary to calculate the offsets of later fields. |
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 think you mean size here, not alignment
Edit: oops, I see that thin What about thin And I absolutely want to be able to use thin |
All of Rust's types are either sized, which implement the
Sized
trait and have a statically known size during compilation, or unsized, which do not implement theSized
trait and are assumed to have a size which can be computed at runtime. However, this dichotomy misses two categories of type - types whose size is unknown during compilation but is a runtime constant, and types whose size can never be known. Supporting the former is a prerequisite to stable scalable vector types and supporting the latter is a prerequisite to unblocking extern types. This RFC proposes a hierarchy ofSized
traits in order to be able to support these use cases.This RFC relies on experimental, yet-to-be-RFC'd const traits, so this is blocked on that. I haven't squashed any of the previous revisions but can do so if/when this is approved. Already discussed in the 2024-11-13 t-lang design meeting with feedback incorporated.
See this comment for the most recent summary of changes to this RFC since it was opened.
Rendered