Among every tutorial/real world example I have yet to come across anyone using the int datatype, I almost thought there wasn't one existing.. Is there a specific reason for uint's uncontested dominance?


It's unusual to need negative numbers. If you don't need negative numbers, there is no reason to use an int, and it's (slightly) easier to write secure code for positive numbers if you don't have to worry about what happens if they're negative. (I say "slightly" because in Solidity you still have to worry about uints overflowing.)

For most practical purposes an int would also work, since everything a uint can represent can also be represented by an int, unless it's a very big number. But if you intend to represent a positive number, you should use a data type intended for representing a positive number.

If you need to handle negative numbers as well as positive numbers, use an int.

  • 1
    In other programming languages, I've seen a check for negative used to check for overflow. Rather than having to reason about what kind of positive number an overflow will result in, a simple check for negative handles it. And having one fewer bit to represent large values rarely matters. For these reasons, the argument is that ints are simpler. Can this trick be used with ints in Solidity also? Nov 13 '17 at 22:58
  • Checking for a negative wouldn't be enough to check for an overflow because it could overflow all the way around again and produce a large positive number. Nov 14 '17 at 2:58

Like the other posters said, if you don't need a negative number. A uint is going to give you more space, also it seems more performant inside the EVM.


  pragma solidity ^0.4.18;
  contract TestInt {
    uint value1;
    function setVal(uint _value) public {
      value1 = _value + 10;

    function getVal() public  returns (uint) {
      return value1;

    int value2;
    function set2(int _value) public {
      value2 = _value + 10;

    function get2() public  returns (int) {
      return value2;
    uint value;
  • The gas difference here is due to the order in which the various functions are listed in the bytecode. It's not to do with int/uint in this case. You can confirm by swapping the ints and uints in your code: same results but the other way round. The actual bytecode generated for each function is identical. Nov 16 '17 at 11:54
  • Ah thanks let me update that, interesting so the order of the functions makes a difference for gas usage? Thats crazy Nov 16 '17 at 12:00
  • 1
    It's just that the code has to step through the function signatures one by one to find out which fn you are calling (think of it as a "switch" statement"). Solidity inserts the signatures into the bytecode in numerical order, so if your function hashes to "0xff123456" then it will take longer to get to (needs more comparisons) than "0x00123456". The gas costs involved are pretty negligible, but if you have a very frequently used function you could name it in such a way that it has a low function signature. But that's a bit extreme! Nov 16 '17 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.