Stream: t-lang/wg-unsafe-code-guidelines

Topic: ucg#102

gnzlbg (Mar 16 2019 at 10:24, on Zulip):

@rkruppe can we answer the question about how big can Rust values be here ?

gnzlbg (Mar 16 2019 at 10:26, on Zulip):

the PR documents the bounds that usize sets because of its use on APIs (size_of/size_of_val, [T; N], ptr.add, etc.) and then it documents the bounds of the current implementation
but guaranteeing the size of Rust values feels RFC worthy

gnzlbg (Mar 16 2019 at 10:26, on Zulip):

for an MVP _implementation-defined_ isn't that bad IMO

rkruppe (Mar 16 2019 at 10:30, on Zulip):

The "bounds set because of APIs" angle doesn't really get to the core of the matter because any one of those just means you can't use that API to work with larger data. But the limitations are more fundamental because they also affect e.g. our codegen for primitive operations such as field or array element projection

rkruppe (Mar 16 2019 at 10:31, on Zulip):

It's useful to document those for sure, but it seems we can't really say anything about the more fundamental limitation without an RFC. Even saying it's impl-defined just punts the issue to the part of the docs that describe rustc's choice of impl-defined parameters, and we can't write those without an RFC either.

rkruppe (Mar 16 2019 at 10:32, on Zulip):

Well, I suppose almost everything in the UCG is provisional without an RFC ratifying it but still

gnzlbg (Mar 16 2019 at 10:34, on Zulip):

One thing we discussed in the next meeting is identifying things that would be RFC worthy, but not belong in the UCG RFC. I think this would be one of those. I'll just change this from "implementation-defined" to "this is how it currently works" but this has not been RFC'ed/

gnzlbg (Mar 16 2019 at 10:37, on Zulip):

done, I'll recycle the issue to track a separate RFC for this - we wanted to start triaging these things next week anyways

Last update: May 26 2020 at 12:15UTC