Maybe? If Option<Infallible> was mistakenly not a ZST I guess it might cost one byte to store the None/ Some discriminator (which would always be None in this example).
> Shouldn't be an authoritative document that says "'this thing' must have 'this size'", or "depends on implementation", "depends on platform" or even "behavior is undefined"?
Well, wait, the current situation is that if the specification doesn't say, Rust isn't promising what size it is. It does say that Option<&T> is the same size as &T, and various other useful things, including an outline of the Guaranteed Niche Optimization, but there are definitely edge cases that are hard to reason about from the human text and it's reasonable to say these are not specified.
I think if your ECU kills people if the size is wrong, you should probably have demanded more than "It wasn't clear in the specification so I asked on GitHub" and so should your regulator if you're in a regulated industry.
If you're happy with "it depends" as an answer then congratulations, Rust can meet that today. But then it seems like you should be more careful with that ECU. I recommend adding hardware failsafe systems so that when, not if, you screw up, you don't kill anybody.
If this is true then the spec should say "using Option<T&> in certain cases carries allocations of undefined size".
Other than forcing me to not use Option<T&> in my embedded systems (which IIRC is widely used), what is the solution? MISRA Rust specs mandating "NO Option<T&>"?
Saying "You used Option<T&> with an edge case. The compiler is not consistent with edge cases sometimes. Don't do that" is shifting the blame on the programmer once again and this is bad for Rust for the reasons everybody knows.
Or I am misintepreting "edge cases that are hard to reason about from the human text".
> you should probably have demanded more
Demanded who? how?
See how difficult is to integrate Rust in an automotive/industrial company like the one I work for?
Who should I sue if I found code generated "out of specs" (specs which don't exist in the first place)?
> ... and so should your regulator if you're in a regulated industry.
But this can't happen right now. I guess regulators will want to rely on ISO or other formal specs for language specifications.
And where is this so-called specification? Do you have a link? Where can I get a hard copy?
Is it this? https://doc.rust-lang.org/reference/
You've smooshed together unrelated phrases with an ellipsis. You're unlikely to learn anything by doing that whether from a specification or really even basic API documentation.
> Or I am misintepreting "edge cases that are hard to reason about from the human text".
Given it isn't anywhere close to the phrase you've decided it's about yes, I'd generously say you are "misinterpreting" it.
> Demanded who? how?
You can explicitly assert claims about the world in your code if you believe they are true but there seems not to be official specifications saying so. Then the code doesn't compile if the assertions are wrong.
In some cases you may find the Rust language team can explicitly clarify something which troubles you, especially if you believe it isn't documented and yet would concern other people too.
And in many cases if you can't see why X is true, you should stop assuming X is true in your safety critical systems.
> Where can I get a hard copy?
This is especially hilarious when people ramble on about ISO because they're always imagining there actually is a "hard copy" of the modern standards. ISO tries really hard to persuade you give them a lot of money to download a PDF of for example 14882:2020 (C++) but you may be able to find a local standards agency who insist they actually have bound copies they can post to you for $$$.
In practice you still won't get a book. Such outfits tend to have a Print On Demand service and ISO 14882 is about 2000 pages so their POD system will reject the print. Once you put your order in, and wait a few days or weeks, either you get a refund and an apology or you'll receive... a CD with the PDF on it. If you have a big University or other technical library nearby they might have an earlier ISO version e.g. C++ 98 and C89 are things some really big libraries actually bought on paper. The standards were smaller and fewer people used PDF readers back then. But they won't have the current versions because it's a waste of money and paper.
Is "Option<&T>" possibly overflowing the stack by at least one byte? You said "maybe?".
And also you said: "the specification (or Rust?) it does say that Option<&T> is the same size as &T".
So???
Is "Option<&T> is the same size as &T" ALWAYS or not???
If it's not, then what I said in my previous comment applies. Otherwise, please be clearer.
> You can explicitly assert claims about the world in your code if you believe they are true but there seems not to be official specifications saying so. Then the code doesn't compile if the assertions are wrong.
"if you believe they are true" is kind-of shifting the blame on me.
> In some cases you may find the Rust language team can explicitly clarify something which troubles you, especially if you believe it isn't documented and yet would concern other people too.
Yes, this is the Github user(s) I mentioned earlier. Is not good enough for an automotive/aerospace/industrial/railway/white goods/etc industry.
> This is especially hilarious
Fine. Where can I get the official PDF with the Rust specifications?
No, although I see where you maybe got confused. I had proposed - as an example of a hypothetical Rust compiler bug - a case where Option<Infallible> might mistakenly not be a ZST even though that's what you'd expect.
It is apparent that you weren't really following, so lets explain a little slower, this will take a few paragraphs and it may require a little extra mental flexibility: In C++ your types all have minimum size 1 byte, Rust goes two sizes smaller.
Consider Rust's generic TryInto trait and its try_into() function:
a = b.try_into().expect("We give up, it's impossible");
Now, what if we tried to turn an unsigned 16-bit integer into a 32-bit unsigned integer? Well that can't fail. We could have the same arrangement, but it's wasteful because there are actually no errors. So we use Infallible here, an Empty Type, making a return type of Result<u32, Infallible>. No values of the Infallible type exist, signifying that although this is a generic function, and other functions of the same kind might fail, this one just cannot.
This Infallible type is pretty useful for such things. But although it's pretty special it is just a type. What happens if we wrap it in Option<> ? Option<Infallible> only has one possible value: None. The Some kind of Option isn't possible because there are no values of type Infallible, and the Some kind needs a value inside it.
In Rust, types with only one possible value are called ZSTs: Zero Size Types. Unlike the Empty type they can exist - there is a value for them, but only one value, so there's no need to store it anywhere, it has Zero Size.
So in my hypothetical the Rust compiler is erroneously not treating Option<Infallible> as a ZST. That seems very unlikely, feels like it just naturally falls out of how the types are defined - but I don't know for sure that the specification says it mustn't happen.
In contrast Rust does specify that Option<&T> and &T are the same size. If that stopped working that would be a major compiler bug, (and it would set off like a bajillion alarms if it broke).
I now realise maybe you were so unfamiliar with Rust that you thought Option<Infallible> was somehow an example of Option<&T>. It isn't at all, and if I'd realised that had confused you I'd have chosen something different. Option<&T> is in human words "Maybe this is a reference to a T, but maybe not", whereas Option<Infallible> is "Maybe this is a failure which can't happen, or maybe not".
> Yes, this is the Github user(s) I mentioned earlier. Is not good enough for an automotive/aerospace/industrial/railway/white goods/etc industry.
I don't believe you that somehow the possibly erroneous text in an ISO document trumps reality, whereas the same isn't true for @m_ou_se or other Rust people's documentation. These are both just words, and the ISO document isn't even describing a concrete system which actually exists. All actual C++ compilers have various deviations from the document, on top of which they have bugs too.
I'm speaking out of ignorance here but, is there a chance of overflowing the stack of a small microcontroller even by one byte with this? Or other side effects on platforms that are not even remotely capable of parsing JSON?
If that's the case and my ECU crashes and people die, should I rely on the fact that an user on Github promised me that the code generated should be correct?
Who ensures this?
Under these conditions, how Ferrocene or the next Greenhills can achieve certifications?
Shouldn't be an authoritative document that says "'this thing' must have 'this size'", or "depends on implementation", "depends on platform" or even "behavior is undefined"?