[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
troplin at bluewin.ch
Mon Jan 13 13:52:23 PST 2014
Carter Schonwald <carter.schonwald at gmail.com>
> 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
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
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)
More information about the Rust-dev