List: make head/tail's expectation of a non-empty list visible in the type system

[kud1ing]

Currently list::head/tail call "fail" when the list is empty.

Haskell's head/tail do the same and it causes a lot of grief: http://www.reddit.com/r/haskell/comments/lf71l/deprecate_preludehead_and_partial_functions/

I suggest to either
a) make the return type an "option"
b) add a "is_not_empty" predicate, similar to vec::head/tail

b) is probably more Rust-nic.

[brson]

Unfortunately we've been getting in the sense lately that predicates are not as useful as we would like. They just end up moving the assertion from inside the function to before every call. In fact, I'm probably going to remove all the predicates from std this week.

We can try making these return option.

[jckarter]

I'd be interested to hear why you guys are deciding to give up on predicates. From the peanut gallery, I thought "moving the assertion from inside the function to before every call" was at least part of the point, to let you get away with writing unsafe inner loops as long as someone in the call chain makes the necessary checks. Is it just that, in practice, that "someone" only ever ends up being the immediate caller?

[brson]

So far, in practice, the check tends to get done by the immediate caller, without regard to whether the check is actually true are false. The result is that functions get a little better documentation, but are much more annoying to use.

Part of the problem might be that we just haven't developed typestate far enough to make it pleasant. Function postconditions, for example, along with carefully designed APIs, could make some predicates hold across longer regions of code. As it is though, there aren't a lot of fans right now among the core developers.

It does make me sad. So much of error handling is coping with bad input, and I was really excited by the prospect of not worring about it. Unfortunately, with the current state of typestate, it makes the implementor's life easy while making the user's life absolutely terrible.

[doublec]

Is there an example of std code that uses predicates that have been showing the issue of making it annoying to use?

[brson]

Not really in std, since most of the heavily used standard functions haven't been given preconditions. There is heavy use of preconditions in a few places in rustc though. The function rustc::middle::trans::GEP_tup_like is an oft-used function with a precondition, and everywhere it's used it is preceded immediately by the check (and often a comment about the check being silly).

https://github.com/graydon/rust/blob/master/src/comp/middle/trans.rs#L689

[kud1ing]

For those not subscribed to "rust-dev":
I've written up some thoughts regarding Typestate: https://mail.mozilla.org/pipermail/rust-dev/2011-December/001149.html

[boggle]

Coming here late, I'm not happy about predicates being removed, this was one of the things that brought me to rust.
I'd rather see us to first to really have preconditions, invariants, and postconditions, and to push hard and try to use them in std before dropping them. Lots of the problems with typestate as it is now may be process issues, i.e. you need to develop/design differently to make full use of it (wonder what eiffelists and DbC people have written about this).

It may also be a good idea to take the extra step and allow limited forms of inference to make typestate more useful though this first would require more experience with using them (inference opportunities: length predicates on vecs, set intersection for (remaining) possible tag variants of a value, logical connectives)

[graydon]

I agree we haven't pushed on typestate nearly hard enough to remove it wholesale (function postconditions don't work yet!) much less played with simple forms of inference.

[kud1ing]

I think using either Typestate or "option" would make list's "head"/tail" equally unpleasant to use.
But Haskell has shown, that this is just necessary.
Should we go for Typestate (analogous to vec's head/tail) then and hope Typestate makes our lives better in the future?

[kud1ing]

Fixed