Carter Schonwald <carter.schonw...@gmail.com> wrote: > indeed, hence why i was saying there should be sized int variants for > each of those semantics (wrapping, trapping, overflowing, etc). This is > something that many people seem to favor, and is the right choice for > supporting smart engineers build reliable sophisticated software. Namely, > really spell out what each alternative means, make sure they're all first > class options, etc etc. > > staticly verifying bounded ranges in a language is really subtle. You're > proposing what easily turns into a pretty tricky flow analysis (to have > it have any precision!), and it'd have to happen in type checker too...
I was actually trying to avoid flow analysis. With my proposal, the range would be "attached" to the type and cannot change over time. That's why I was proposing a case match binding for going to a smaller range. Some time ago I was reading a blog post (I think it was from Patrick Walton) about why you abandoned type state and how it can be replaced with a less dynamic system that is easier to reason about. In that system the dynamic type state was replaced by a more static type parameter. I don't want type state for integers but this 'replacement'. (I don't know how it was called, need to read it up again) Tobi _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
