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

Topic: bool == _Bool


gnzlbg (Dec 07 2018 at 14:34, on Zulip):

@RalfJ ehmm I actually argued that we should remain compatible with C ? I opened that issue because of due process, because most of you actually agreed that supporting platforms that are "weird" was not worth doing

gnzlbg (Dec 07 2018 at 14:35, on Zulip):

saying bool == _Bool is incompatible with CHAR_BITS == 8 and pretty much anything else with respect to C FFI AFAICT

RalfJ (Dec 07 2018 at 14:40, on Zulip):

@gnzlbg I don't care the slightest what we say about the size of bool

RalfJ (Dec 07 2018 at 14:41, on Zulip):

saying bool == _Bool is incompatible with CHAR_BITS == 8 and pretty much anything else with respect to C FFI AFAICT

no it isn't?

RalfJ (Dec 07 2018 at 14:41, on Zulip):

CHAR_BITS == 8 just means "we dont care about platforms where that condition does not hold"

gnzlbg (Dec 07 2018 at 14:41, on Zulip):

If CHAR_BITS != 8, then bool != _Bool

RalfJ (Dec 07 2018 at 14:41, on Zulip):

no

RalfJ (Dec 07 2018 at 14:41, on Zulip):

it just makes such platforms out-of-scope

RalfJ (Dec 07 2018 at 14:41, on Zulip):

bool == _Bool means "on all platforms we support, this holds"

RalfJ (Dec 07 2018 at 14:43, on Zulip):

or, put differently: CHAR_BITS == 8 means that we pretend that platforms where CHAR_BITS != 8 do not exist. If they happen to exist (and I know they do but that's not the point), we just do not care about them, do not want to support them.

RalfJ (Dec 07 2018 at 14:43, on Zulip):

I do not see how that in any way implies anything about bool

gnzlbg (Dec 07 2018 at 14:45, on Zulip):

bool == _Bool means on all platform we will ever support, this must hold, not just "hold on C FFI"

RalfJ (Dec 07 2018 at 14:46, on Zulip):

yes?

gnzlbg (Dec 07 2018 at 14:46, on Zulip):

this means that if the requirement bool == _Bool cannot be satisfied, then that platform cannot be targetted at all AFAICT

RalfJ (Dec 07 2018 at 14:46, on Zulip):

and all platforms we ever support will have CHAR_BITS == 8

RalfJ (Dec 07 2018 at 14:46, on Zulip):

that's what "assuming CHAR_BITS == 8" means

gnzlbg (Dec 07 2018 at 14:47, on Zulip):

not really

RalfJ (Dec 07 2018 at 14:47, on Zulip):

I dont know what you mean by "hold on C FFI".

RalfJ (Dec 07 2018 at 14:47, on Zulip):

not really

what else could it mean? we make an assumption, so platforms that dont satisfy that assumption are not supported.

gnzlbg (Dec 07 2018 at 14:47, on Zulip):

the difference is that CHAR_BITS == 8is required to, e.g., use a bool properly in C FFI, if C has a CHAR_BITS == 16, then you could pass an u16 to communicate a "bool" with C

RalfJ (Dec 07 2018 at 14:48, on Zulip):

if C has CHAR_BITS == 16 Rust does not run on that platform.

gnzlbg (Dec 07 2018 at 14:49, on Zulip):

why not ?

RalfJ (Dec 07 2018 at 14:49, on Zulip):

you said yourself we assume CHAR_BITS == 8

gnzlbg (Dec 07 2018 at 14:49, on Zulip):

of course it does, as long as you don't use C FFI, it doesn't really matter

RalfJ (Dec 07 2018 at 14:49, on Zulip):

you are really confusing me^^

gnzlbg (Dec 07 2018 at 14:49, on Zulip):

we expect CHAR_BITS == 8 to be able to do C FFI with some Rust types with a C ABI

RalfJ (Dec 07 2018 at 14:49, on Zulip):

oh, you are saying CHAR_BITS == 8 is just a requirement to do C FFI? not a requirement to run at all on that platform?

RalfJ (Dec 07 2018 at 14:50, on Zulip):

that's not at all how I read these things

gnzlbg (Dec 07 2018 at 14:50, on Zulip):

iff CHAR_BITS != 8, then we can't maybe use bool on C FFI, but we could use something else

RalfJ (Dec 07 2018 at 14:50, on Zulip):

even assuming that is the intended interpretation (not sure if it is, doesnt sound unreasonable): this still means that if CHAR_BITS != 8, you cannot do FFI, so _Bool literally doesnt matter

gnzlbg (Dec 07 2018 at 14:51, on Zulip):

you can do FFI, but not necessarily with the same types that you use in a platform where CHAR_BITS == 8.

RalfJ (Dec 07 2018 at 14:51, on Zulip):

talking about C types like _Bool only makes sense in the context of FFI

RalfJ (Dec 07 2018 at 14:52, on Zulip):

you can do FFI, but not necessarily with the same types that you use in a platform where CHAR_BITS == 8.

now you are really stretching the assumption here. I think that is an unreasonable interpretation.

gnzlbg (Dec 07 2018 at 14:52, on Zulip):

the difference is that bool == _Bool impacts all Rust code using bool, not just the tiny portion of code trying to communicate with C's _Bool via C FFI

RalfJ (Dec 07 2018 at 14:52, on Zulip):

we said CHAR_BITS == 8 because other platforms are so niche we dont care about them

RalfJ (Dec 07 2018 at 14:52, on Zulip):

because we dont want to have these silly discussions

RalfJ (Dec 07 2018 at 14:53, on Zulip):

now you are reinterpreting that statement in a way such that suddenly platforms violating our assumtpions can matter again. that's not what these assumptions are for.

gnzlbg (Dec 07 2018 at 14:53, on Zulip):

@briansmith mentioned that they rely on doing C FFI with those platforms

RalfJ (Dec 07 2018 at 14:53, on Zulip):

well, they should talk with @Gankro then who declared such platforms out-of-scope

gnzlbg (Dec 07 2018 at 14:54, on Zulip):

@Gankro also declared platforms with bool == _Bool out of scope

RalfJ (Dec 07 2018 at 14:54, on Zulip):

you mean !=?

gnzlbg (Dec 07 2018 at 14:54, on Zulip):

when they stated that we don't care about bool with size != 1

RalfJ (Dec 07 2018 at 14:54, on Zulip):

well that statement is tautological

RalfJ (Dec 07 2018 at 14:54, on Zulip):

we defined bool == _Bool so it holds for all supported platforms^^

Gankro (Dec 07 2018 at 14:55, on Zulip):

what platforms is brian doing this on?

RalfJ (Dec 07 2018 at 14:55, on Zulip):

so this is really a discussion about some people anyway wanting to support such obscure platforms. okay. but then let's frame it as such, not pretend that this is about bool which it isn't.

gnzlbg (Dec 07 2018 at 14:56, on Zulip):

? @RalfJ I argued that bool with size == 1 is the only thing worth supporting in Rust

gnzlbg (Dec 07 2018 at 14:56, on Zulip):

that does not imply that doing C FFI with platforms where the machine code on the other side expects something different has to be impossible

RalfJ (Dec 07 2018 at 14:56, on Zulip):

@gnzlbg you argued that bool == _Bool is somehow incompatible with CHAR_SIZE == 8. I think that's logically wrong. that's why I commented.

gnzlbg (Dec 07 2018 at 14:57, on Zulip):

it is, because _Bool is defined for all CHAR_SIZEs

RalfJ (Dec 07 2018 at 14:58, on Zulip):

it is not, because we cant do no FFI on platforms on which we dont support FFI, and hence _Bool just doesnt matter there. if your goal is to add sizeof(_Bool) == 1 to our platforms requirements, that's cool, but please say so :)

gnzlbg (Dec 07 2018 at 14:58, on Zulip):

no, i am not proposing that, i proposed that bool has size of 1, _Bool can have whatever size it wants, doesn't really matter

gnzlbg (Dec 07 2018 at 14:59, on Zulip):

if _Bool has size 2, and our bool has size 1, then if you only write Rust code, or C code, and they don't interact, then both programs are correct and work and are portable

gnzlbg (Dec 07 2018 at 15:00, on Zulip):

the problem is if you try to use bool in C FFI, and the other side (C, assembly, or some other code) expects a type with size 2, and you provide a type with size 1

gnzlbg (Dec 07 2018 at 15:00, on Zulip):

then that's a problem, but if on the Rust side you pass an u16, and then cast it to a bool, then that's ok

RalfJ (Dec 07 2018 at 15:00, on Zulip):

I am not willing to follow your strange interpretation of "no FFI support for CHAR_SIZE != 8" meaning "you can still do FFI but have to be a bit more careful around integer types". I think "no FFI support for CHAR_SIZE != 8" means "no FFI support for CHAR_SIZE != 8" and if you insist on doing FFI anyway, literally anything might happen and your use case is just too niche for us to even consider it in these discussions.

gnzlbg (Dec 07 2018 at 15:01, on Zulip):

so for you, if C breaks any of Rust requirements, no C FFI is possible at all

RalfJ (Dec 07 2018 at 15:01, on Zulip):

yes

RalfJ (Dec 07 2018 at 15:02, on Zulip):

that's the point of making such assumptions

RalfJ (Dec 07 2018 at 15:02, on Zulip):

so that we dont have to spend our afternoons discussing arcane platforms^^

gnzlbg (Dec 07 2018 at 15:02, on Zulip):

so I am 100% against that

gnzlbg (Dec 07 2018 at 15:02, on Zulip):

the assumptions aren't a zero sum game

RalfJ (Dec 07 2018 at 15:03, on Zulip):

so you want some kind of "degraded FFI" to still be possible for platforms violating platform assumptions?

gnzlbg (Dec 07 2018 at 15:03, on Zulip):

the thing is, we use C FFI for interacting with everything that is not rust

gnzlbg (Dec 07 2018 at 15:04, on Zulip):

if I have a 99.999999% Rust program, and need to link an assembly blob and call it via C FFI, i am in control of everything, and don't really care what the size of _Bool in the platform is, only what Rust actually expects

RalfJ (Dec 07 2018 at 15:04, on Zulip):

I can see why you would want that, but I don't think that "we only support C with CHAR_SIZE == 8" leaves room for that interpretaion. so I think what you are proposing is to go back even further and say that we do want to support some things on CHAR_SIZE != 8. you have to take it up with @Gankro from there, I don't really have a stanza here ;)

gnzlbg (Dec 07 2018 at 15:05, on Zulip):

so forbidding all C FFI is just too much

Gankro (Dec 07 2018 at 15:05, on Zulip):

i can live with it, but I just want some concrete platforms we care about enabling with this

gnzlbg (Dec 07 2018 at 15:05, on Zulip):

I think that if bool != _Bool then using bool on C FFI should just warn that bool is an improper C type

gnzlbg (Dec 07 2018 at 15:06, on Zulip):

we can then specify bool as it makes sense for Rust, and it just so happens that it makes sense for all C platforms that we support today (and who knows, maybe ever)

gnzlbg (Dec 07 2018 at 15:07, on Zulip):

if a C platform does not support it how we need it, then people will need to figure out how to interface with that platform via C FFI, but that should not require making bools weird for all Rust code

gnzlbg (Dec 07 2018 at 15:08, on Zulip):

it should not make interfacing with the platform impossible either

RalfJ (Dec 07 2018 at 15:13, on Zulip):

the goal of that decision (bool == _Bool) was to avoid people using a c_bool type for FFI. your proposal is in direct contradiction to that.

gnzlbg (Dec 07 2018 at 15:13, on Zulip):

And the rationale of the decision stated that another goal was for people to use bool in Rust instead of u8 to get a "1 byte wide" bool, but that goal was not met with the decision

RalfJ (Dec 07 2018 at 15:14, on Zulip):

I think it is fairly clear from the text that the teams were aware that this could mean that bool has size != 1 on some platforms

RalfJ (Dec 07 2018 at 15:15, on Zulip):

boats explicitly wrote

We document this, and also document that on every platform we currently support, this means that the size of bool is 1.

RalfJ (Dec 07 2018 at 15:15, on Zulip):

so I dont know why you claim they wanted bool to have size 1 on all platforms

gnzlbg (Dec 07 2018 at 15:15, on Zulip):

Yet @Gankro and others have argued since that guaranteeing that bool has a size of 1 is worth it because supporting those platforms isn't worth it

gnzlbg (Dec 07 2018 at 15:16, on Zulip):

you seem to be arguing that supporting those platforms isn't worth it yourself

RalfJ (Dec 07 2018 at 15:16, on Zulip):

nono dont shift arguments

RalfJ (Dec 07 2018 at 15:16, on Zulip):

first, the team decision

gnzlbg (Dec 07 2018 at 15:17, on Zulip):

as i mentioned, is unclear, the PR that implemented the decision just specified that bool has size of 1, but I suppose that's what they meant with only documenting it for the platforms that we support now

gnzlbg (Dec 07 2018 at 15:18, on Zulip):

@Gankro 's Layout and ABI post sets it as size of 1, not as _Bool

RalfJ (Dec 07 2018 at 15:18, on Zulip):

do you argee that they were aware that this could mean bool has size != 1 on some platforms?

gnzlbg (Dec 07 2018 at 15:19, on Zulip):

they were aware, and they were aware that that could be a problem

gnzlbg (Dec 07 2018 at 15:19, on Zulip):

but all options have problems

RalfJ (Dec 07 2018 at 15:19, on Zulip):

and they decided anyway. so let's document that.

gnzlbg (Dec 07 2018 at 15:20, on Zulip):

i was tasked in the last meeting to open an issue an involve those from those dicussions to 1) clarify more precisely what they meant, and 2) discuss new information

RalfJ (Dec 07 2018 at 15:20, on Zulip):

and then you and @Gankro and @briansmith can discuss which assumptions we make about C platforms, and which consequences that has, and maybe you want to write an RFC to change the bool decision. but @Gankro's proposed requirements are not in contradiction with the team decision, nor is any subset of them. you just dont like the consequences of that decision combined with some undecided assumptions.

gnzlbg (Dec 07 2018 at 15:20, on Zulip):

that @avadacatavra post should document bool == _Bool for the time being until that was resolved was also decided in the last meeting

gnzlbg (Dec 07 2018 at 15:21, on Zulip):

i don't recall saying anything about an RFC, somebody argued that when that decision was made not all options might have been considered

gnzlbg (Dec 07 2018 at 15:22, on Zulip):

e.g. the possibility of diagnosing improper usage of bool on C FFI on the platforms in which its usage is not proper

RalfJ (Dec 07 2018 at 15:22, on Zulip):

I think you need an RFC to change that decision

gnzlbg (Dec 07 2018 at 15:23, on Zulip):

maybe? its unclear whether its even worth changing, which is why the issue was opened

gnzlbg (Dec 07 2018 at 15:25, on Zulip):

even if it would be worth changing, none of those decision went through the RFC process, so a mini-FCP might be enough

RalfJ (Dec 07 2018 at 15:25, on Zulip):

but anyway, I am going to do something else now because I learned what I wanted to learn from this discussion^^ I hope maybe I was able to at least convey why the way you are framing things is terribly confusing.

If I could make a suggestion: start by writing down the high-level problem statement ("which kind of platforms do we want to support FFI on, and what consequences does it have on the rest of the language if we support certain arcane things, and how badly do things degrade on non-supported platforms"). There's an entire matrix of possible decisions and consequences here and only in a few cells of this matrix does the bool == _Bool decision become a problem. Starting with some nitty-gritty detail that is a consequence of several not-yet-made-decisions is really hard to follow.

gnzlbg (Dec 07 2018 at 15:27, on Zulip):

That's what the first post of the issue attempted to do

RalfJ (Dec 07 2018 at 15:29, on Zulip):

the title says it's all about bool, but I think if I understood one thing here then its that that's not the case

gnzlbg (Dec 07 2018 at 15:30, on Zulip):

If we just say bool == _Bool then unsafe code cannot rely on the size of bool, the bit patterns of true and false, etc.

gnzlbg (Dec 07 2018 at 15:30, on Zulip):

transmute might comply loudly about this, but type punning through an union won't

gnzlbg (Dec 07 2018 at 15:31, on Zulip):

guaranteeing anything more at all about bool is incompatible with the T-lang and T-compiler decision that bool == _Bool

RalfJ (Dec 07 2018 at 15:31, on Zulip):

I agree with that observation

RalfJ (Dec 07 2018 at 15:32, on Zulip):

but that is a discussion that's mostly independent of C platform requirements and FFI

RalfJ (Dec 07 2018 at 15:33, on Zulip):

there is an intersection at "we could just require the C platform to be like most of them are"

gnzlbg (Dec 07 2018 at 15:33, on Zulip):

if C20 and C++20 goes as expected, then the bit patterns of bool become fixed, as long as we require C20 compatibility, which the T-compiler and T-lang did not do, otherwise they still are unspecified

gnzlbg (Dec 07 2018 at 15:33, on Zulip):

the size of bool would still remain unspecified

RalfJ (Dec 07 2018 at 15:33, on Zulip):

but both discussions (the bool discussion and the C platform requirements discussion) go way beyond that, and your issue is mixing all of these three things up in a messy way I'm afraid

gnzlbg (Dec 07 2018 at 15:37, on Zulip):

I mean the issue has two questions at the end that would be nice to resolve: what C standard does _Bool need to abide, if any ? (If we don't specify any, unsafe Rust can at most assume C99) If we specify one, then that fixes some things that unsafe Rust is allowed to assume about bool

gnzlbg (Dec 07 2018 at 15:38, on Zulip):

And the second question is: do we want / is it worth it to require bool to have a size and alignment of 1. That would be something that unsafe Rust would be able to assume that it cannot assume right now.

gnzlbg (Dec 07 2018 at 15:39, on Zulip):

Even if UCG just says "bool == _Bool" it would be nicer if it could say _Bool according to which C standard.

rkruppe (Dec 07 2018 at 15:44, on Zulip):

I don't have the time to be dragged deep into this discussion but I want to point out that besides "C platforms with weird bools" being mostly or entirely hypothetical, code (including unsafe code) can assume things that are not technically true about every platform Rust might ever target (such as maybe bool being a byte), if it only works on platforms where that is true. Bools are not the first and by far not the most realistic example where one might want to do that. "Complete portability" including to such weirdo platforms is neither achievable nor desirable for 99.99% of software anyway, as I have argued previously.

gnzlbg (Dec 07 2018 at 16:26, on Zulip):

@rkruppe the question is whether we should guarantee that so that most people don't have to assume this "at their own risk"

gnzlbg (Dec 07 2018 at 16:26, on Zulip):

people targetting platforms with weird bools are going to have bigger problems than "I can't use bool on C FFI and c_bool is not a thing".

rkruppe (Dec 07 2018 at 16:27, on Zulip):

The ship for such a simple question has sailed. Now it's knee deep in "wtf even is C in practice" and other annoying enigmas.

gnzlbg (Dec 07 2018 at 16:27, on Zulip):

we should not make targetting those platforms "impossible", but I don't think it is worth it to leave all properties of bool unspecified just to make something hard only slightly less hard

gnzlbg (Dec 07 2018 at 16:28, on Zulip):

@rkruppe what do you mean with "has sailed" ?

rkruppe (Dec 07 2018 at 16:30, on Zulip):

We're now in the situation that we have a settled policy/framing that covers all the remotely normal platforms. Even raising the possibility of re-litigating bool layout necessarily gets deep into hypothetical or long-dead platforms and the extremely hard and annoying topic of "platforms with no/outdated/non-conforming C platforms".

rkruppe (Dec 07 2018 at 16:30, on Zulip):

Which is also why this is such an intensely frustrating discussion.

RalfJ (Dec 07 2018 at 16:31, on Zulip):

it's not "at their own risk". it's unsafe code being less portable than general Rust code. That's okay, they should just document that (and ideally make sure that their code fails to compile on unsupported platforms)

gnzlbg (Dec 07 2018 at 16:32, on Zulip):

they might need to test for bitpatterns of true and false and many other annoying things

RalfJ (Dec 07 2018 at 16:32, on Zulip):

updating our notion of _Bool together with C/C++ seems perfectly reasonable, I dont think anyone would disagree with that

RalfJ (Dec 07 2018 at 16:32, on Zulip):

so the only remaining question is the size

RalfJ (Dec 07 2018 at 16:33, on Zulip):

all it takes is for someone to write a crate that performs bool <-> u8 conversion (checked and unchecked) and makes sure it fails to compile if the types dont match. then tell everyone else to use that crate if they really need to inspect bool bit-wise. no magic needed.

gnzlbg (Dec 07 2018 at 16:33, on Zulip):

What value does leaving the size unspecified add ?

RalfJ (Dec 07 2018 at 16:34, on Zulip):

supporting FFI on platforms where the size is different

RalfJ (Dec 07 2018 at 16:34, on Zulip):

I dont know if we should care

RalfJ (Dec 07 2018 at 16:34, on Zulip):

just saying both options are reasonable

rkruppe (Dec 07 2018 at 16:34, on Zulip):

also, technical conformance with C/C++, which eliminates one reason why people might think they need a c_bool

rkruppe (Dec 07 2018 at 16:35, on Zulip):

(at least "more" conformance, depending on the version of C and C++ in question)

gnzlbg (Dec 07 2018 at 16:35, on Zulip):

I don't know what real value that adds. Chances are, lot of Rust code won't be usable on those platforms either =/

gnzlbg (Dec 07 2018 at 16:35, on Zulip):

Would definitely be one thing less to deal with when porting existing code to those platforms

rkruppe (Dec 07 2018 at 16:36, on Zulip):

I think the concern boats cited -- people worrying about FFI mismatches and defining/seeking a c_bool type -- is a real danger even if, as is currently the case, _Bool is a byte on every platform Rust is ever ported to

rkruppe (Dec 07 2018 at 16:36, on Zulip):

it's not a portability danger, but a danger to code quality and people's time

gnzlbg (Dec 07 2018 at 16:36, on Zulip):

i think so too

RalfJ (Dec 07 2018 at 16:37, on Zulip):

though clearly the decision made by the teams then is also a danger of people's time because it seems we are going to have this discussion every 2 years or so^^

rkruppe (Dec 07 2018 at 16:37, on Zulip):

but it's the time of the sort of nerd who willingly gets into this sort of debate, not the time of normal rust users

RalfJ (Dec 07 2018 at 16:38, on Zulip):

I got nerdsniped. I dont even care about portability. :P

gnzlbg (Dec 07 2018 at 16:38, on Zulip):

boats also mentioned the opposite concern, that people would use struct Bool(u8) in Rust to make sure that in such platforms some bools are indeed 1 byte wide

gnzlbg (Dec 07 2018 at 16:38, on Zulip):

i got nerdsniped too

gnzlbg (Dec 07 2018 at 16:40, on Zulip):

honestly I wish we would just have gone the c_bool way

rkruppe (Dec 07 2018 at 16:41, on Zulip):

I wish C wasn't such a vague standard

gnzlbg (Dec 07 2018 at 16:41, on Zulip):

those are type aliases, not new types, so you can pass bool to it and call it a day

rkruppe (Dec 07 2018 at 16:42, on Zulip):

I know if it's a type alias some people are going to treat them as separate types anyway and develop a phobia to just using bool in FFI-adjacent Rust code

gnzlbg (Dec 07 2018 at 16:42, on Zulip):

I just don't write FFI-adjacent code that often

gnzlbg (Dec 07 2018 at 16:43, on Zulip):

I find the trade off of sane reliable bools everywhere with a bit of "unfounded" paranoia in C FFI code acceptable

rkruppe (Dec 07 2018 at 16:44, on Zulip):

I really don't care strongly enough about hypothetical weirdo platforms which effectively puts me in the camp of the status quo (which is bool == _Bool)

gnzlbg (Dec 07 2018 at 16:44, on Zulip):

users doing C FFI have to know better anyways

rkruppe (Dec 07 2018 at 16:44, on Zulip):

I'll leave it at that

RalfJ (Dec 07 2018 at 16:45, on Zulip):

I really don't care strongly enough about hypothetical weirdo platforms which effectively puts me in the camp of the status quo (which is bool == _Bool)

I think you are in camp "require sizeof(_Bool) == 1 for FFI", which is different (it is stronger)

rkruppe (Dec 07 2018 at 16:46, on Zulip):

bool == _Bool is explicitly the standing team decision, I don't care enough about the subject to tease out corollaries from it (if this even is one)

gnzlbg (Dec 07 2018 at 16:47, on Zulip):

if one never targets a platform where sizeof(_Bool) != 1 then it doesn't really matter whether that is required or not, you can just assume it

gnzlbg (Dec 07 2018 at 16:47, on Zulip):

and write code accordingly

RalfJ (Dec 07 2018 at 16:50, on Zulip):

@rkruppe it's not a corollary. I just interpreted your "dont care about weirdo platforms".

briansmith (Dec 07 2018 at 17:01, on Zulip):

@gnzlbg I haven't followed the whole discussion but I didn't say that I need to support any platform with CHAR_BITS != 8 nor _Bool not being equivalent to Rust's bool.

briansmith (Dec 07 2018 at 17:02, on Zulip):

IIRC, I did say that it seems possible to support platforms that have a different representation of _Bool by just not allowing bool in #[repr(C)] types and not allowing bool in extern "C" declarations when targetting those platforms.

briansmith (Dec 07 2018 at 17:02, on Zulip):

Whether that's a good idea or not, I don't know and I don't particularly care.

briansmith (Dec 07 2018 at 17:04, on Zulip):

Last year there was some effort to define a mechanism to say that certain platforms don't support certain things. For example, it is very useful to allow impl From<u32> for usize and impl From<usize> for u64 and it would work fine 99% of the time, but if you want to support 16-bit platforms then you can't have impl From<u32> for usize on that platform.

briansmith (Dec 07 2018 at 17:06, on Zulip):

It seems like a more general problem and if there were a more general solution to this kind of subsetting then I think it would also solve disputes like this. But a more general subsetting mechanism seems to have made no progress.

Last update: Nov 19 2019 at 18:50UTC