Why is uint so popular

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 `uint`s 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`.

• 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 `int`s are simpler. Can this trick be used with `int`s in Solidity also? – Jonathan Tran 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. – Edmund Edgar 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.

https://ethfiddle.com/mCES1Jc3bH

``````  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 `int`s and `uints` in your code: same results but the other way round. The actual bytecode generated for each function is identical. – benjaminion 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 – Matthew Campbell Nov 16 '17 at 12:00
• 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! – benjaminion Nov 16 '17 at 12:05