Skip to content

Remove typestate, etc. #2178

@brson

Description

@brson
Contributor

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.

Activity

catamorphism

catamorphism commented on Apr 9, 2012

@catamorphism
Contributor

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

brson commented on Apr 9, 2012

@brson
ContributorAuthor

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

catamorphism

catamorphism commented on Apr 10, 2012

@catamorphism
Contributor

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

brson commented on Apr 10, 2012

@brson
ContributorAuthor

Continuing to push on typestate would also be good.

catamorphism

catamorphism commented on Apr 10, 2012

@catamorphism
Contributor

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

graydon commented on Apr 10, 2012

@graydon
Contributor

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

nikomatsakis commented on Apr 10, 2012

@nikomatsakis
Contributor

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

nikomatsakis commented on Apr 10, 2012

@nikomatsakis
Contributor

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

graydon commented on Apr 10, 2012

@graydon
Contributor

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

pcwalton commented on Apr 11, 2012

@pcwalton
Contributor

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

catamorphism commented on Apr 19, 2012

@catamorphism
Contributor

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.

4 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @graydon@brson@nikomatsakis@pcwalton@catamorphism

        Issue actions

          Remove typestate, etc. · Issue #2178 · rust-lang/rust