Use `int` as the type if a number will never be negative?

<p>Is it okay to use <code>int</code> instead of <code>uint</code> as the type even if you know the number will never be negative, so you don&#39;t have to convert <code>int</code> to <code>uint</code> all day?</p> <hr/>**评论：**<br/><br/>mackstann: <pre><p>If you have no specific need for it to be unsigned, then using a regular int is perfectly fine, and more convenient.</p></pre>im_10xer_bro: <pre><p>this is what The Go Programming Language recommends, with the specific example of uints being useful when you want to do bitwise operations</p></pre>earthboundkid: <pre><p><code>uint</code> should generally only be used for doing binary operations, bit flags, etc. because even if a value can’t be negative there might still be a case where you want to loop from N to zero or detect an overflow. </p></pre>anaerobic_lifeform: <pre><p>Do you recommend using signed integers because they wrap around?</p></pre>earthboundkid: <pre><p>All fixed size numbers wrap around, it&#39;s just a matter of will you catch it or not. It&#39;s more likely that if a positive number suddenly turns negative that you&#39;ll catch it than if a large number happens to become a smaller one.</p></pre>unstablevacuum: <pre><p>In general, the drawback of using an unsigned int type to enforce positive values is that you lose the ability to test for an unexpected negative value. You can assert that n &gt;= 0 if n is signed, but the assertion will always pass if n is unsigned, even if your code unintentionally does something that would have made n negative.</p></pre>soapysops: <pre><p>If you have to convert constantly, then consider using <code>uint</code>. But in general prefer <code>int</code>, <code>int64</code>, and/or <code>float64</code> for almost all of your code. Also, using <code>uint</code> in particular is pretty rare. Usually if you want something unsigned then you need it to be a specific size too.</p> <p>Don&#39;t use unsigned types to enforce or suggest that a number must be positive. That&#39;s not what they&#39;re for. The compiler doesn&#39;t check that they never go negative or that they never wrap around. And usually they just increase the probability that someone makes a mistake by incorrectly converting an <code>int</code> to a <code>uint</code> (or an <code>int64</code> to a <code>uint64</code>).</p></pre>Testiclese: <pre><p>unsigned integers behave &#34;weirdly&#34; when close to 0. Signed numbers behave &#34;weirdly&#34; when close to their max value. You&#39;re more likely to be close to 0 than to the maximum.</p> <p>Unsigned numbers are useful for bitwise operations, but I rarely see them used elsewhere. </p> <p>Another useful property of signed ints is using negative values as the &#34;absence&#34; of a value. </p> <pre><code>maxVal := getTheMax() if maxVal &lt; 0 { fmt.Println(&#34;no max value defined&#34;) } </code></pre> <p>Dumb example but you get the point. Using unsigned, you&#39;d have to pick 0 as &#34;absence&#34;, which might cause problems if a max value of 0 indicates &#34;presence&#34; as well. Your other solution would be to use a pointer-to-integer which requires extra indirection and could be worse. </p> <p>There&#39;s a reason the Java creators excluded unsigned numbers from the language - too much abuse from people who don&#39;t understand them. </p></pre>__crackers__: <pre><p>Yes. I don’t know why (Go is my first language that has unsigned ints), but it’s very common in Go. Also in the standard library.</p></pre>jerf: <pre><p>The &#34;why&#34; is that numbers underflow and overflow and don&#39;t have any trap or signal or anything else when it happens, and for some reason 98% of programmers consider this hunky-dory and actively fight the idea of putting such things in our languages, which I can only presume is because &#34;that&#39;s how it&#39;s always been done&#34; because there is almost no other argument against it trapping being the default that makes any sense. (Well, there&#39;s the performance one, but if we all used it, the CPUs would catch up, so I don&#39;t put much stock in this.)</p> <p>If we had trapping, I could easily recommend using unsigned numbers when you want something to always be positive. But in reality, where unsigned numbers have a near-certainty of suddenly becoming multi-billion without warning or error, is difficult to recommend them. Using signed numbers for such things means you may still get unexpected negatives, but at least then your bug creates a <em>cleanly detectable</em> invalid state, which during debugging is better that getting large numbers and trying to heuristically decide if it&#39;s invalid.</p> <p>As you might pick up, this drives me crazy. Personally I find the idea of adding two positive numbers and getting a negative without any warning to be an absolute disaster and an atrocity that has demonstrably caused thousands of security issues (by my estimation, this is security issue number 3, behind being memory-unsafe and casual string concatenation causing all kinds of cross-X attacks), but the vast majority of programmers not only think that&#39;s just fine, but think people who disagree are weird. </p> <p>I suppose it&#39;s hardly the only place I disagree with the vast majority, though.</p></pre>__crackers__: <pre><p>Thanks for the explanation.</p> <blockquote> <p>Personally I find the idea of adding two positive numbers and getting a negative without any warning to be an absolute disaster and an atrocity</p> </blockquote> <p>Coming from a Python background, yes, that is insane.</p></pre>drvd: <pre><p>Yes. ints are number and uints are bitvectors. No need to cramp a non-negative number into a bitvector just because it is possible and bitvectors provide +, -, *, etc.</p></pre>MisterSkilly: <pre><p>If you&#39;re fine with just half the numbers being available, sure!</p></pre>