On 11-12-26 02:34 PM, Rust wrote:
I've been thinking about the unhappiness with Typestate (see e.g. issue
#1105).
I think the example in that bug is probably not a good candidate for
typestate, at least as it currently stands. Lists are constantly being
destructured and empty-list is a valid return from 'tail' when working
with lists, even if we had working function postconditions.
So
let a = [1, 2, 3]; let b = vec::head(vec::tail(a));
could be deduced to compile and be correct, if we could
1) make Typestate know that some functions ("tail()" in this example)
change properties, which are relevant to the predicates it verifies
2) make Typestate backtrack those property changes and predicates.
Does that make sense?
It "makes sense" in the sense that people have designed systems that do
this and you could design such a system for Rust. It would not use any
of the mechanisms of the existing typestate system.
The road you're going down is called 'dependent types', and we're not
going to be writing a dependent-typed language here; it's more cognitive
load than we can possibly cram in while maintaining coherence, IMO.
You probably want ATS, which is Hongwei Xi's current research vehicle.
It's a great language. It's also far more complex than Rust, and we're
not going to be emulating most of those features here.
If typestate turns out to be unusable for anything interesting in its
current level-of-power -- plus or minus minor usability adjustments --
we're more likely to remove it altogether than try to enhance it to the
theoretical level of dependent types. They're a Big Deal.
There's still a lot of unfinished work in typestate-as-designed though.
We need function postconditions and some form of constraint-carrying
types, and may well want to have a careful kind of check-inference pass
for simple predicates. The feature's not done yet, it's just resting.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
