Hacker News Reader

Comment by virtualritz | Hacker News Reader

I think types should express intend.

This adds more 'value' to the code for people than allowing them to switch their brains off because something is 'unlikely' to happen. A large class of bugs exists because people assume stuff is unlikely.

I also think one has to distinguish between API and actual code.

If you write a lib that takes inputs that should never be negative you can express this without writing a single line of documentation about it (or if you do, requiring the user to read it) by using unsigned types in these places.

You can still use signed types in your actual library code if you want/must/believe in that but do not pollute the outside API with them if unnecessary.

View on HN

In most languages that offer this distinction, unsigned integers also don't really express your intent in an effective way.

Imagine you have a bug in your program. If you intend for a value to be non-negative and use a signed integer, you get a negative value. Your code is broken. You didn't want a negative value. But you do have have a very easy way of checking for this at runtime, at least.

Now imagine you instead use an unsigned integer. The bug is still there but now it manifests as overflow or underflow. Your program is still broken. Nothing about using an unsigned integer saved you. And worse, you don't have an easy predicate to check that something has gone wrong.

I think this can only be a reasonable choice if you are working in a language that has dynamic checks for overflow and so using an unsigned integer enforces not only the predicate that the value is nonnegative but also that all operations stay within its expected arithmetic domain.

If my intent is that a certain integer should never be negative, labelling it unsigned does a poor job at conveying this intent because any arithmetic just silently does the wrong thing. 3-4 is some huge number rather than “error”.

In Rust, 3u64 - 4u64 is "error", specifically

thread 'main' panicked at 'attempt to subtract with overflow'

It panics _in debug builds_ but wraps in release builds because including the checks in every arithmetic operation is not zero cost.

Though you can configure your release builds to panic as well. That can be quite useful if you don't expect trivial computations to be a large cost center (and you can always bench to check that assumption).

Even more so now that custom profiles have been added to Cargo (yay), you can enable overflow checking in release, and add a `release-unchecked` or whatever.

Or, better in many cases, you can write what you meant explicitly in Rust.

3u64.checked_sub(4u64).expect("Overflow");

This allows you to spell out that you don't expect this to overflow, and Rust should panic if it does, regardless of your compiler flags.

Of course you can do that, but I would say that doing so defensively for every operation is way more verbose and unwieldy than you'd want.

Much simpler to just toggle on the relevant flag.

I think GP was saying you can do that when you expect that the general case doesn’t need to be checked but a specific case does.

> when you expect that the general case doesn’t need to be checked but a specific case does.

But surely that's almost never the case? Few programs actually desire or care for base 2 modular arithmetics, and when they do it tends to be for very specific tasks (usually cryptographic or cryptography-adjacent e.g. hashing, checksumming, ...).

> But surely that's almost never the case?

Which is why it’s not so impractical to make an occasional exception.

I wish they had "unchecked_sub()" instead, and default "-" would work like checked_sub().

unchecked_sub() exists in Nightly and so may some day come to stable

However, changing - to perform checked_sub() leaves you with an Option, and this makes ordinary arithmetic look pretty clumsy:

let x = (a-b).unwrap()-c;

The intent is to land more types with intrinsic behaviour. Today only the Wrapping type is provided, so Wrapping<i32> is an i32 that definitely has Wrapping arithmetic and won't panic on overflow, but eventually Saturating<i16> will be possible (e.g. for CD audio PCM samples, saturating arithmetic is correct, if you try to make the loudest possible noise louder it just stays the same) and so will Unchecked<i8> if you really sure that you're doing 8-bit arithmetic that can't overflow and doesn't need Debug checks.

This sounds like an issue with the language. 3-4 is not a large number and should not be by default. It should be a case handled by the developer.

Maybe you want to do some weird bit banging trickery, and that's fine too, but it should require an out-of-the-way function call.

> This sounds like an issue with the language. 3-4 is not a large number and should not be by default

Many languages optimize numeric operations and DX around numeric types for efficiency rather than correctness, and make the latter high-friction. (Wrap-around subtraction, decimal literals being treated as IEEE floats, etc.)

The exceptions (or cases where it is merely less true) tend to be very high level, dynamic languages.

But then your function should check if the value is within reasonable parameters.

If it was an int at the function signature and you got -1 what would you expect to happen? It's the same thing.

> But then your function should check if the value is within reasonable parameters

How could you possibly check this using types that cannot represent what you are checking for?

> How could you possibly check this using types that cannot represent what you are checking for?

`f(u32 a, u32 b) { assert a > b ... `

(if the hypothetical following operation is `a-b` as discussed higher in the thread)

Better ensure that assert is not turned off in release mode then.

One of the reasons I don't like asserts.

Log the error and act accordingly, instead of believing this kind of issue only happens during development

How do you "act" if you detected your logic is faulty? In many situations aborting is the best choice.

If input data is faulty and the reason for that is not seen as part of your logic, then sure, log an error and skip.

I used to define my own assert macro to "ensure" my asserts aren't disabled, but I don't bother anymore. There's nothing wrong with assert, and you needn't define NDEBUG. It's important to be aware that there are different situations, and not all warrant aborting, as described above. Another differentation is that there can be asserts that must be disabled in release builds for performance reasons, and others that won't affect performance and can stay enabled.

An unsigned integer will never be negative, that intent is expressed clearly and correctly. What the operational semantics should be is unclear, because of the tradeoffs involved in signaling an error.

In terms of the C standard, "3-4" for unsigned ints is modular arithmetic, and the "wrong thing" is assuming that it will do anything other than wrap around. This is very clearly defined, and implied whenever you see an arithmetic expression on unsigned integers.

Conversion from signed to unsigned is implicit and silent. The expression being converted to your "can never be negative" type isn't nonnegative!!! Its value drastically changes; e.g. -3 becomes a huge number.

Not if you pass -Wconversion to GCC

Clearly defined, but very inconvenient and makes it too easy to write buggy code that looks correct on surface.

Inconvenient to whom? It’s pretty inconvenient not to do that if you eg have strict memory/performance requirements.

C made the right tradeoff IMO. You can protect yourself against overflow if you need to, but if it always signals errors you can’t turn that off.

> because any arithmetic just silently does the wrong thing

The same thing, but worse, can happen with signed integers. (-3)-INT_MAX is either some huge positive number, or something crazy because it's undefined behavior and the compiler is allowed to do anything it wants.

I guess what the parent is saying is that, while the same kind of bugs can happen with signed integers, they are less common than with unsigned integers because they typically involve very big or very small values such as INT_MAX or INT_MIN. This is due to the fact that the "most common values" (close to 0) are at the beginning of the range of unsigned integers, but at the middle of the range of signed integers, so the risk of underflow is lower for signed integers in practice.

I can understand where they come from, especially regarding error handling: for integers whose value must not be negative, it is easier to check for underflow by checking if the result is not negative rather than by checking that the result is not eg smaller than the previous value (eg for addition).

That being said, "number must not be negative" really ought to be encoded in the type system, so that the user of the type knows that they must actually look for underflow.

I guess that part of the problem is that we don't want to check for underflow after each operation, so checking the negativity is a way to "coalesce" several checks after multiple operations. However this is fragile, because the multiple operations could end up producing a positive value, even if some intermediate values where negative.

For full safety, I don't see how we could do better than checking after each operation right now. If we're doing this, I feel like checked_add and friends from rust is a better fit than cramming an unsigned int into a signed one.

I wonder if we could design an integer type with 63 bits of value, plus one bit of "overflow/underflow poison", such that any operation that would under/overflow would saturate that bit to one, but otherwise still perform the operation on the value part. That would allow to coalesce multiple checks while keeping safety even in the presence of multiple faulty operations. I wonder how it could be implemented efficiently though

> I wonder if we could design an integer type with 63 bits of value, plus one bit of "overflow/underflow poison", such that any operation that would under/overflow would saturate that bit to one, but otherwise still perform the operation on the value part. That would allow to coalesce multiple checks while keeping safety even in the presence of multiple faulty operations. I wonder how it could be implemented efficiently though

There is something like that already for floating point. Whenever an overflow or underflow happens, it sets a sticky bit in a separate flags register. You can clear these flags, do a sequence of operations, and at the end, see if any of these flags are set. See https://man7.org/linux/man-pages/man3/fenv.3.html for the standard C API for it.

Your idea for a coalescing overflow type has been explored in the document N2868 [0], a proposal for the C programming language. Instead of reserving a bit from the integer, each integer type is associated with a checked integer type, which holds an integer alongside an overflow bit. Checked integers are opaque and can only be constructed and deconstructed via macros; as I understand it, the idea is that the compiler can use the processor's preexisting overflow flag to represent the checked integer. In particular, the operations on checked integers have the property of coalescing overflow checks that you are looking for.

[0] Supplemental Integer Safety, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2868.pdf

"unsigned" doesn't express intent. It expresses implementation, maybe it expresses assumption.

Ada's "Positive" or "Natural" or

  subtype X is Integer range Y..Z;

expresses intent (well expresses requirement really), it also enforces that constraint, so it's not merely an assumption.

> I think types should express intent. > If you write a lib that takes inputs that should never be negative you can express this without writing a single line of documentation

So, let's make an odd_int_less_than_20587 type and a billion of other types? "Not negative" normally helps only one tiny bit towards documenting anything about the accepted values. Making a separate type for that and complicating everything is ridiculous.

> If you write a lib that takes inputs that should never be negative

Have you ever compared the difference between two unsigned integers? Because unsigned integers don't have "natural" subtraction. Did you ever find the need for signed numbers to interact with unsigned numbers? Because if you did, it's a bad idea to separate them without need. Premature isolation is a prime cause of complexity.

> So, let's make an odd_int_less_than_20587 type and a billion of other types?

Bounded integer types have been extremely useful for me on a few occassions, and I wish more languages had type systems powerful enough to support them. They also address your concerns about subtraction.

I think you assume my comments are regarding C/C++.

They are not. I write mostly Rust these days.

I don't really care, why would Rust be much different in that regard?

> So, let's make an odd_int_less_than_20587 type and a billion of other types?

Yes, what's wrong with that ? Every variable's type should be defined as precisely as possible when meaningful, that's the whole point (and C/C++ not easily allowing to do that is one of their biggest drawbacks imho.)

There's a tradeoff around strictness of nominal types and evolvability, e.g. changing the threshold on such a strict type would be a breaking change.

Changing the threshold without signaling the change in the type system is also a breaking change. It's just that your compiler won't warn you about it when you inevitably forget to update your code. Instead your code is going to break at runtime.

Not necessarily, it depends on what you do with the value.

Obviously if you have at most 8/16/32/64 bit types (only making new types because of physical constraints), you'll have way, way fewer breaking changes than if you try to encode bounds extremely tightly and try to update them whenever you 2 instead of 1 somewhere.

In fact most software is designed such that the physical sizes are chosen first, and then the practical bounds follow from that.

Are you seriously asking? Because what I suggested rhetorically would be the death of all your programs for the simple cause that line count would quadruple and you would have to touch half your codebase every time you make a tiny change.

When I make a change today like renaming a method I just let my IDE apply it to the codebase, why would that be different ?

Because if you change one type to include the number 235498 it will also affect 377 other types.

why would it ? if you set things such that expected ranges are set where they matter (e.g. where you do arithmetic) you should only have to change the types for which range issues occur, like this (very quick and dirty, likely wrong, but you get the idea): https://gcc.godbolt.org/z/4v6dW9czP

Not to hurt anyone's feelings but no I don't get the idea. I find this irritating and very unconvincing. So much work and boilerplate to prove peanuts. Have you ever seen anyone doing serious software development like that? I mean, not just toy examples of some 10-line bean counting program blown up to 100 lines.

> void foo(ranged_int<1, 5> a, ranged_int<3, 7> b)

Why would I _ever_ write a function like that? Practical proofs need to be about runtime values, not just constants and types. They also need to put multiple values in relation. They need to handle type casts and many more things. Constant integer ranges might be of some use but it's a tiny fraction of the invariants that a programmer juggles in practice, and the source code is already blown up out of proportion just for these ranges. This thing is just not gonna fly.

Just multiply some "good" values a few times and there is no way that you can statically prove that the result is going to be in the range as well, even though it might always be the case due to how the values combine each time (simple example: offset + size that the code checked to be within array bounds). Invariants in practice are relations over the runtime values of multiple variables. The focus on single values is basically already where types fail as a correctness tool.

> Just multiply some "good" values a few times and there is no way that you can statically prove that the result is going to be in the range as well, even though it might always be the case due to how the values combine each time (simple example: offset + size that the code checked to be within array bounds).

I don't understand, there's literally a CVE about that elsewhere in this thread, basically

    struct my_structure { 
      int size;
      int offset;
    };

either you restrict both size and offset to e.g. 2^30 so that you can safely sum both, or you will have an issue because you'll be doing if(size + offset < max_size) and size + offset overflows because absolutely no one can be trusted to write overflow checks, you gotta use a library for that.

If you're not making assumptions about the values stored in your variables, then every little arithmetic operation can lead to unexpected wraps (UB for signed types). What follows is that we need to make assumptions. Don't write an if conditional in front of every operation like a forgetful person - but assume that "my_structure" contains good values that you can safely add.

Usually it's very easy - require that size and offset are validly indexing an object, and require that objects are of a sane size (I rarely have in-memory objects larger than a few megabytes, and for most code I posit that it is a mistake to not chunk and stream huge datasets). Done, no real need to worry.

If you cannot make any assumptions about the values contained in a "my_structure" then that means the code is at an API boundary, which is the perfect place where such check (if-statement) must be placed. At internal code places, checks are wasted effort, and at most a compiler switch to detect wraps (logic errors) would often be a much better choice than paranoid code where each line of code can't trust the previous line, and where one can't see actual work being done because it's all covered in mistrust. Unnecessary mistrust (i.e. mistrust at places strictly inside maintenance boundaries which are not strategic checkpoints) only makes it hard to write code that actually does something, and might possibly cause more bugs than it could ever save.

> So, let's make an odd_int_less_than_20587 type and a billion of other types?

Yees?

Bounded integers are a relatively common feature of programming languages (and one which is sorely missing from Rust, it's technically possible currently but not super fun, when fleshed out enough const generics should make them much nicer, possibly even built-in)

What is the point of bounded integers? Most quantities don't have natural bounds, and practical bounds only arise from physical limitations (8/16/32/64 bit etc).

Those practical bounds have a tendency to percolate into bounding other things. So you can only have 2**10 foos because they're indexed by a 10-bit bitfield somewhere? Now maybe you can only have 204 bars, because every bar has at least 5 foos. And so on.

If you genuinely wanted to reason solidly about such limits, you do end up needing arbitrarily bounded integers. Of course, most people don't want to do that, for good reasons. And even if you wanted it, there's a reasonable question whether adding them to the language syntax is really the right thing to do.

Yup, that kinda was my point, and where you say "at least" that is also a good point why setting up some complicated static system to maintain limits is not practical. Hence my philosophy has been for a long time to set the physical constraints that just have to be decided (and do that as best as I can). And then to not worry (more than a tiny bit) about statically deciding the rest, or it'll end in a nightmare.

Not every type pays it’s way, but the distinction between N and Z is well worn and useful. N measures the size of things while Z is a little more abstract. I think u64 can quickly convey a powerful intent.

If we're talking about N and Z (which makes sense since most programs are grounded in a mathematical model with some physical constraints added on top), then please acknowledge that N doesn't have subtraction defined, which illustrates why it's not very useful for most code.

You could also argue that subtraction for unsigned numbers is only partially defined, just like for signed numbers. But that would be missing the point, since most numbers in practical programs are small, and for these numbers the signed range is indeed much more useful since subtraction is defined for signed integers (e.g. i32) for small numbers. This is not the case for unsigned, where 3u-4u is usually not what you want.

Even without subtraction defined, N is useful. Partial subtraction on N, as it is, is also useful. When I'm dealing with counts I pretty explicitly either want truncated subtraction or warnings when I overflow.

Perhaps the biggest issue all together is just that many languages will let you do 3u - 4u instead of outright making the syntax more obviously annoying to force you to think about the caveats and pick between {truncated, throwing, overflow} variants.

> So, let's make an odd_int_less_than_20587 type and a billion of other types?

Yes, and at least in C++ it isn't that difficult to trivially generate these types as you need them with a modicum of template-fu. You don't need that many integer type templates to capture most of the common cases and provide contextually sane operators. This might be a little more difficult in other languages.

This is pretty standard type safety practice and usually well worth it in terms of writing robust low-defect code.

Show me where this is standard safety practice?

Eh, what? This has been idiomatic for many years for C++. Not doing it, especially today, is just malpractice. Every company I've worked at since I was doing C++ professionally required this. There is no accounting for how random companies do their software engineering but that doesn't mean competent software engineering organizations don't exist.

I do database engines. This has been a standard part of code standards for a really long time, at least as long as the programming languages we used practically supported it. I've done it ever since. The only type that is allowed to flow through the code is size_t, where it makes sense.

I'm really curious what that means and how it looks. I assume it's casually going beyond simple typedefs for types whose size might change? And what does "flow through the code" mean here? That you can't mention "int" or "uint64_t" anywhere? That you can't pass these things as arguments?

Are there any open source examples to study this style? I don't know where to look, but admittedly studying C++ codebases is not what I do for fun.

In my personal experience, it never worked putting layers of abstractions to hide physical representations. That makes the implementation code really hard to grok, and your hands are bound in the code because you're not allowed to _assume_. What worked for me instead is making sure that certain decisions that are likely to change are contained inside a module and for the rest of the code hidden behind an API or simply not accessible. Runtime assertions can be useful too, but maybe that is part of what you are describing by "template-foo". Finally, I try to stay true to my decisions and am not trying to act like I could have to replace floats by doubles at every corner. Some code that I've seen was littered with templates for that single reason, and I'm pretty sure the developers didn't have an intimate understanding how floating points works.

Interestingly, size_t is one of the things that I tend to avoid, and in my perception a majority of the programmer population agrees it was a mistake to have it be an unsigned type. A type which can represent "the size of an object" is too general for all but maybe OS APIs IMO. Usually I know that the size of my objects is bounded by a certain size, well below what fits in 32 bits.

Totally!

This is one of the best features of the pascal family:

http://www.delphibasics.co.uk/Article.asp?Name=Sets

(look in "SubRanges")

Almost useless in my opinion (because not a lot of practical invariants can be expressed with simple ranges) and will only create confusion when using non-0, non-1 based indexing and also create confusion about the representation/the space required for representation. The examples shown there are similar to the Animal-Cat-Dog examples that are popular to "prove" that classes and inheritance are useful.

That, plus the type incompatibility that arises from mixing such types with other integer types.

Do you have uses Pascal?

The ones that used it like it...

I have worked on an enterprise application written in Delphi full-time for 6 months.

> So, let's make an odd_int_less_than_20587 type and a billion of other types?

I see your point, but I think that (while not always), it can still be pretty helpful to add your custom types to make invalid states unrepresentable.

This can sound ridiculous on something like C, but if your language has refined types, it's not that bad.

For example, this doesn't look awful to me:

``` type WeirdId = Int Refined (Odd And Less[20587])

val myId: WeirdId = 5 // OK val myInt: Int = myId // Can be used as an Int val myRuntimeId: Either[String, WeirdId] = refineV[Odd And Less[20587]](myId + 2) // Runtime Check val myInvalidId: WeirdId = 6 // Compilation Error ```

https://scastie.scala-lang.org/qoSHgL4PQCW6lC2MUHc5YA

I've spent some time pondering things like that, but ultimately concluded that we should keep these things away because there is a duplication between type-level and code level, and I'm completely fine with sprinkling a few runtime assertions in most cases. Normal code syntax is much more suited to expressing invariants. Obviously I'm not into statically proving the correctness of my programs, so if that's your cup of tea things are probably looking different (and I'm sorry for you).

I would love to be able to do more formal proving of programs in practice, but I 100% agree with you. A lot of what the advanced typing crowd seem to be doing is to re-invent programming but at the type level, and it's unclear to me why that should count as progress. It reminds me uncomfortably of C++ template metaprogramming -- and for good reasons, C++ has made steps towards replacing that with statically evaluated expressions written in regular syntax.

My gut feeling is that the right way forward is to have a fairly standard type system visible in the source language augmented by contracts written in regular code. Basically a slight augmentation of assert(). A formal prover could internally reason about an extended type system where those contracts are automatically lifted to the type level if that helps for some reason, but programmers wouldn't be bothered with it.

This seems unlikely to be a genuinely novel idea, so I'd be curious to hear whether systems like that already exist.

Exactly. It pains me when someone comes up with a new language with dependent types, but then to encode a simple constraint they first define integers via peano axioms using some kind of template metaprogramming. (The example I'm remembering was Coq or a Haskell dialect or something.)

There was a dialect of C#, Sing# or Spec#, that allowed you to specifying pre and post conditions in the same expression language as the main language, and they were checked at compile time. This is what comes closest I think.

It does not express intent. I remember being a junior C programmer and using "unsigned" to express my intent (it's greater than or equal to zero).

In reality, like all C keywords, it's completely misleading and actually really means "weird_arithmetic_mode_that_will_mess_you_up".

I don't know what's misleading about it or how the arithmetic is weird?

Signed and unsigned integer types both are finite fields, rather than Abelian rings like the normal integers used in most math. That difference makes the arithmetic "weird", but going to signed integers doesn't change anything, anything except bigints (or generic arbitrary precision floating point) is a form of "weird_arithmetic_mode_that_will_mess_you_up" if you pretend you're operating over the real numbers.

Not sure what they mean about it being misleading though. They might prefer it if they were called "modular integers" instead of "unsigned integers" but that would lead to confusion with modules IMO.

>Not sure what they mean about it being misleading though. They might prefer it if they were called "modular integers" instead of "unsigned integers" but that would lead to confusion with modules IMO.

Modular integers to me would seem very confusing. They're integers without the sign, and they have some max value determined by the number of bits, I can't really think of a better name for them except for the fixed-width versions which include that bit information.

Extremely intuitive, simple English words, exactly what it says it is (integer without the sign bit).

Imagine a parallel situation. There is a type `NonEmptySet`, with an `intersection` operation. Now, given `NonEmptySet(1, 2).intersection(NonEmptySet(3, 4))`, and the requirement that `intersection` produces another `NonEmptySet` what does that return? How about a set containing everything except 1, 2, 3, 4? Does that seem reasonable? That's analagous to what `(unsigned)3 - (unsigned)4` does.

In short, the operations on `unsigned int` do not really behave like "non-negative integer"; as such it's a weird match to use them for that purpose.

I don't really see it, unsigned says there's no sign. Given that and the number of bits it's exactly the expected behavior that it will not be able to produce a sensible result for subtracting something larger from something smaller.

Whether the operation then errors out or wraps doesn't change anything about unsigned being the right name for it, because it's something you wouldn't expect unsigned to do.

The intersection of your two NonEmptySet produces an empty set. If you write that result into a NonEmptySet it's the same, it doesn't make sense for you to expect a NonEmptySet as a result of that operation.

In a perfect world, this would be so. And if there were types that were performant AND could enforce such invariants without the downsides, I'd welcome them gladly. But primitive types come with baggage and limitations, so you have to make compromises. And the compromises when using unsigned ints are just too costly in my opinion. They're a good tool for specific use cases, but not as good as signed for general purpose code.

Could you list some of the downsides & compromises in the case I made?

- silent unintended underflow behavior

- dangers of mixed signed/unsigned code (signed values MUST exist, but unsigned values don't have to)

- more cognitive load to read and understand unsigned underflow detection code + issues once you exceed the halfway point

This is why Java offered signed integer types only (I think they should have allowed unsigned as well, but for different reasons)

> silent unintended underflow behavior

Please show me an example in the wild that could not be trivially caught/alleviated. With 'trivially' I mean the code that needs to be written to prevent it, not the thinking you need to do to consider it.

As for the latter: this is what I get paid for. Writing the code out is necessary but not what I really get paid for (unless I were a very slow typist, that is).

I find that most of the time I was simply too lazy. Or rather: I wrote C/C++ code for 20+ years. I used int and didn't think (unintended rhyme).

Now I write (mostly) Rust I find myself considering the edge cases regularly and also covering them because the compiler forces me to. See also this comment [1].

I.e. a - 1 + b where a is always positive (incl. 0) and b is always > 1 'just' works with int (and unsigned [overflow] too!) in C/C++.

In Rust you will get a panic when a = 0 which will then make you think what you're doing and simply reorder this to a + b - 1.

I find that this is the 'cognitive load' that needs to be applied commonly and I'm pretty fine with that.

> dangers of mixed signed/unsigned code

Alleviated by simply not mixing. There is a reason languages like Rust simply do not allow this without explicit typecasts. And those, in cases where one type is signed and the other is not and they have equal width translate to "all bets are off".

> more cognitive load to read and understand unsigned underflow detection code [...]

See first point. IMHO this is simply the same point expressed differently. Underflow happens when you subtract.

Ensure you do not subtract a larger value from a smaller. This is as easy as writing max(a, b) - min(a, b) or what author of [1] does.

Same as abs(a - b) but works with unsigned. Cognitive load? I do not see any and I agree with the author of the article that this is easier to read.

[1] https://news.ycombinator.com/item?id=29767877

This is one of those "If everyone would just do X" kinds of situations, which is why I'm against it. Things go wrong all the time - in fact it's a miracle anything works at all. So when I see "code that needs to be written to prevent it", I let out a sardonic laugh; people just don't work that way.

People WILL forget to check, or implement the check wrong (and it won't be discovered until the next black swan event), or some invariant will change in future and nobody will know to update this code. The code doesn't care because the compiler doesn't enforce the invariants, so you're left with bare and likely confusing (and probably eventually undefined) behavior.

I for one would LOVE it if popular languages could be instructed to inject invariant enforcement code (not asserts) at certain boundaries. It would help with a whole host of problems!

When you cross zero with a signed integer calculation, it's easy to find out, and the code has low cognitive overhead. Also, with code generally structured this way, bad input propagation tends to get stopped earlier because of the number of functions that check against negative values.

It's also possible to underflow check with unsigned, but the code is more complicated and can't stop propagation if it fails, and if you are allowing values > the signed positive limit (or unwittingly allowing it), your overflow detection code gets even more complicated (or wrong) due to the reduced overhead space. You COULD do a bunch of checks beforehand, but that's not always feasible due to the combination of operations being done on the operands, and once again people are people.

Even though many modern languages block uncast type conversions, that still doesn't protect you from converting a negative integer to an unsigned integer. Yes, you SHOULD be checking before the cast, buuuuuuut...

What we want to do is reduce the number of ways things can go wrong, reduce the fallout of an errant process, and minimize cognitive load to reduce bugs overall. Making that worse just to double the positive integer space doesn't make sense to me.

Here's an example:

  unsigned int length_a = 10;
  unsigned int length_b = 20;

  if (length_a - length_b < 0)
  {
      printf("negative diff\n");
  }
  else
  {
      printf("positive diff\n");
  }

I would argue that there is plenty of code like that in the wild. It looks innocent and harmless but it gives a completely surprising result.

If you ignore the compiler warning. This is trivial for the compiler to detect.

only in the most trivial cases

https://gcc.godbolt.org/z/YWPP5qdbx

-Werror

I don't understand why the programming language can't promote the temporary to a larger signed int. Of course you can't change it in C anymore, but its like this in most languages. But you rarely ever want unsigned modulo arithmetic here (and if you do it should be a special syntax).

"This value should never be negative, so I'll use an unsigned type." There are two types of programmers: ones who are reassured by that reasoning, and ones who shudder at it.

Yeah, "should not" and "can not" aren't the same at all.

In C or C++, if you write a function void api(unsigned), you can cheerfully call it as api(-42) or api(b - c) where b - c are int.

This is a poor, poor substitute for contract checking.

Types aren't always expressive enough for that. I usually can't specify that a number should always be negative for instance, or that there's no 0.

My preference is to minimize surprise. If everyone is used to using signed types for everything, you better have a good reason for using something else, and leave that justification in a comment

> I think types should express intend.

Yes, and let's start with overflow behavior because it's much more relevant than the type domain.

If overflow isn't encoded by the type, there is just no way to correctly set a strict domain.

What you want is range subtypes of signed integers.

Important: without silent conversion. Languages like Pascal and Ada require explicit conversions in more places to make that sort of thing useful.

It also allows creating type checked "new" numerical types for semantics purposes to help improve interfaces. This helps prevent things like accidentally passing an integer in the wrong units for example. Two of the worst offenders I've seen of this is: "Is this uint64_t (or float) "dt" parameter in ticks, seconds, milliseconds, microseconds or nanoseconds?" and "Is this angle parameter in radians or degrees?"

And why also limit to that? What if I have a function that accepts values in the range [0, 100]? Make a type to express that? What if I have a function that takes only positive integers (i.e. unsigned integers minus 0)? Chances are that you should anyway validate your input. Also what if you have a function that takes an unsigned and a signed is passed? On most situations you only get a warning (or not even that) and it's passed a completely wrong input to the function. Isn't better to take an int and validate it before doing anything with that?

You see, doesn't make a lot of sense to distinguish between positive and negative in the end. From a mathematical point of view negative integers have the same dignity of positive integers since a couple of centuries. The same operations that apply on positive integers apply on negative integers, and not only that, an operation between two positive integers can as well result in a negative integer!

The unsigned type was created just to have one more bit if you *are sure* you have only positive integers. That could had a sense in the era of 8/16 computers. Nowadays that we have 32 or 64 bit computers does really that extra bit count that much? I don't think so... 2 billions is plenty enough for most usages.

Reply on news.ycombinator.com