3 ms·

Sorry if I misinterpreted. That's why I am asking (and you moved into personal). Is "Option<&T>" possibly overflowing the stack by at least one byte? You said

by scoutt 4y ago

Sorry if I misinterpreted. That's why I am asking (and you moved into personal). 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?

tialaramex 4y ago
> Is "Option<&T>" possibly overflowing the stack by at least one byte? You said "maybe?". 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"); Sometimes for example we can (losslessly) convert a signed 16-bit integer to a 32-bit unsigned integer, but, sometimes it's negative and we can't. So, with a 32-bit unsigned a and a 16-bit signed b this function has something like Result<u32, Error> return type, because we either get Ok with our converted u32 or we get the Error. Cool. 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.
- scoutt 4y ago
  OK, thanks. I know about niches/elision and I didn't though Option<Infallible> as an example of Option<&T> and, backtracking, I was confused by "It does say that Option<&T> is the same size as &T," followed somewhere by "but there are definitely edge cases". I did mentioned I was maybe misinterpreting what followed that phrase.

by scoutt 4y ago

tialaramex 4y ago

> Is "Option<&T>" possibly overflowing the stack by at least one byte? You said "maybe?". 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"); Sometimes for example we can (losslessly) convert a signed 16-bit integer to a 32-bit unsigned integer, but, sometimes it's negative and we can't. So, with a 32-bit unsigned a and a 16-bit signed b this function has something like Result<u32, Error> return type, because we either get Ok with our converted u32 or we get the Error. Cool. 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.

scoutt 4y ago
OK, thanks. I know about niches/elision and I didn't though Option<Infallible> as an example of Option<&T> and, backtracking, I was confused by "It does say that Option<&T> is the same size as &T," followed somewhere by "but there are definitely edge cases". I did mentioned I was maybe misinterpreting what followed that phrase.