Remove typestate, etc.

[brson]

Typestate does a lot of things, most of which we don't use. It's the longest compiler pass, discounting trans. Without it we can get rid of check, if check, claim, pure, constraints.

I like the idea of typestate, but it's not pulling its weight.

[catamorphism]

You mean removing user-specified constraints? Or also getting rid of late initialization and early returns?

It's possible to do the first, but it wouldn't eliminate that much code since most of it is still needed to check definite-assignment and must-return anyway.

[brson]

I mean removing everything that we don't rely upon, and probably rewriting whatever is left to be faster.

[catamorphism]

Ok. The code has never been optimized and should certainly be rewritten. To me that's separate from the language design question. Removing constraints altogether seems premature to me. As far as I know, they're not used not because they aren't useful (there are lots of places where they would be useful just in the compiler), but because people found the overhead of using them (as far as cognitive burden) to be too high. I'm not seeing the evidence that there isn't a more usable design that still lets us state more precise properties about code. It's not like we've tried to revise the design and failed to find something that works better -- there just haven't been enough person-hours available to do so. I think it's worth putting in some effort there before we raise the white flag completely.

[brson]

Continuing to push on typestate would also be good.

[catamorphism]

There just has to be someone to do it. I'm reluctant for that person to be me, because the longer I'm the only one who works on / uses it, the less anyone else will believe that it's really something they want to use :-) Intern project?

[graydon]

I feel a sense of deja vu here wrt. issue #1805

I posted what I felt then and nobody's had time to do anything new with typestate since then -- indeed, @catamorphism moved to doing classes specifically to get involved with the rest of the compiler, leaving typestate aside to come back to it later -- so my preference is mostly the same as then:

#1805 (comment)
#1805 (comment)

It's a bit like the macro system. It's not dead, it's just resting. I still want to give it a chance.

[nikomatsakis]

I am eager to reimplement it. I think it can be made substantially faster. That said, I am not convinced yet of its worth---I haven't seen a use yet that could not also have been achieved with types. However, I have used it a few times and even caught a bug that might have gone unnoticed otherwise (though as I said I could have used types to catch that same bug, albeit in a non-obvious way).

[nikomatsakis]

Still I do think that if we want to simplify the language, @brson is right that type state is not "carrying its weight" with regard to language complexity. But I guess we're not quite at the "simplify" stage yet---still in the "expand" stage.

[graydon]

We're ostensibly in the "simplify" stage -- so says the manual! -- I just don't think the next appropriate simplification to typestate is "remove it entirely". I think that's premature given the number of incomplete portions, lack of recent attention, number of plausibly-useful reduced-functionality DBC-like or contract-like forms it could assume, and the fact that we need at very least the init-predicate tracking for memory safety (hard to emulate any other way given the existence of move operators and whatnot).

[pcwalton]

We definitely need init to stay. For that reason we need typestate to stay around, even if it morphs into just our version of Flow.java.

We should also think about what a DBC system would look like. Something like DBC + QuickCheck might be pretty awesome for unit testing.

[catamorphism]

I see a pretty clear lack of consensus, so I'm closing this, but there are certainly discussions in the comments that we should go back to.