Hey there! Often people compare Solidity and JS. The latter one have so-called Signed zero. I was wondering how do Solidity deals with this issue, but couldn’t find any explanations on this one. Could you explain this one a bit, or point me to the relevant information!
P.s. Sorry if I chose a wrong category – pls, move the topic if so. Link is just out of search, no affiliations.
More or less the only thing Solidity and Javascript have in common is the keyword “function”.
The type system works completely different and is more like C’s or Rust’s.
There is no such things as a signed zero in Solidity. For a uint8, for example, the only values are the integers between and including 0 and 255. A uint8 variable cannot have values like null, undefined or NaN.
I’d add that the signed zero in JavaScript is just a consequence of the language using the IEEE-754 floating-point representation for all numbers, even integers. Floating-point numbers have a designated sign bit so you can have positive zero (value=0, bit not set) and negative zero (value=0, bit set). See Floating-point arithmetic > Internal representation.
This is a bit unusual and different from most other programming languages, including Solidity, where integers are a separate type. For signed integers negative numbers are represented using 2’s complement and there’s exactly one zero value,
Insightful answer, thank you! Started to grasp the thing. And will read the page on 2’s complement more thoroughly.
Btw, are there any plans to introduce floating-point in Solidity, or is it against core principles of EVM as a whole?
P.s. Found out that I already had interest in this page on representation during learning the basics of smart-contracts, but without your explanation couldn’t connect the dots.
Btw, are there any plans to introduce floating-point in Solidity, or is it against core principles of EVM as a whole?
No plans currently. There are no EVM opcodes for handling floats. At the EVM level everything is a 256-bit integer. Floating-point numbers would have to be emulated. Fixed-point numbers have a simpler representation so they’re cheaper and that’s what we’re targeting. People are already de facto using them in practice - e.g. the decimals field in ERC20 effectively makes token amounts a fixed-point number - so it’s mostly matter of explicit syntax for using them.
We were originally planning to add support for primitive fixed-point types and they’re even already present in the syntax (see Fixed Point Numbers) but they’re currently disabled and no operations on them are implemented. The problem is that there’s more than one way to implement them and each one comes with upsides and downsides. We couldn’t agree on one canonical way to do this and we’re headed in a different direction now - we want to make it easy for libraries to provide their preferred implementation via User Defined Value Types.
P.s. Found out that I already had interest in this page on representation during learning the basics of smart-contracts, but without your explanation couldn’t connect the dots.
Well, this is because it’s a bit out of scope of our docs 
We have to assume familiarity with some fundamental concepts and this is one of them. The binary representation of integers is inherited from actual hardware and therefore is a thing you’ll see in most programming languages. It’s just now that many people come to programming through JavaScript, they’re getting exposed to this concept much later than they used to.
I don’t think we want to expand on that too much but we could always add a link to some good external resource that explains the fundamentals. Feel free to submit a PR if you want to improve that part of the docs.