Original title: “Implicit Overflow Considered Harmful (and how to fix it)”
Stories with similar links:
- Implicit Overflow Considered Harmful (and how to fix it) via meithecatte 1 year ago | 9 points | 7 comments
Original title: “Implicit Overflow Considered Harmful (and how to fix it)”
We want i8 to be true subtype of i16. When I say subtype I mean true subtype as in PLT, i. e. I want true Liskov Substitution Principle. But in real programming language this is not true. Because i8 and i16 represented differently. I. e. you cannot use struct containing i8 everywhere you use same struct, but with i16. Because of representation issues. But in this article novel way is proposed: decouple range from representation! Now you get true subtypes (as in PLT). And in the same time you get better overflow management! And in the same time you keep decent performance! And no any undefined behavior! BRILLIANT!
Sounds like integer from common lisp: http://clhs.lisp.se/Body/t_intege.htm#integer
That was my thought, too.
IIRC, Ada has a similar idea, where you can declare integer types using a range, and the compiler decides how to store it.
Also I recommend reading other posts in this blog. They are very insightful. For example, this article https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html proves that any language with mutability (i. e. all popular languages except for Haskell) should have something like Rust’s borrow checker. All languages, not only low-level ones or performance-oriented. You should have borrow checker. Not for speed, but for correctness. Also this gives argument why Rust is best language. Not “best within fast languages”. Simply “best”. Best of all languages with mutability
Looks very clever, but IIRC range subtyping is very difficult, if not impossible??? I could very well be wrong.
That said, lots of things are very difficult but still have Good Enough practical solutions, so.
This proposal separates range and representation, and thus makes range subtyping possible
This article is brilliant! One of the best articles I have read for a long time.
I want to create my own language. Like many people here. :) And this article gave me a lot of insight, I will certainly use this ideas in my language