The Trusted Iterator Length Problem

[reem]

Oh, I would just have exact_size be an unsafe method and implementing it would therefore require typing unsafe.

[huon]

@reem, that’s the problem that @P1start (and the rest of the thread ) is describing: a method declared unsafe in the trait doesn’t require the implementer to write unsafe.

[reem]

That seems wrong then.

[tbu]

Currently the unsafe declaration in the trait just means that the function is unsafe to call, so it might have to fulfill a contract. This doesn’t necessarily mean that every implementation of this function has to rely on that contract, and when they don’t they can just omit the unsafe.

[bluss]

We need real specialization based on optionally available traits. An impl of an unsafe trait TrustedIteratorLength could be present, and functions should be able to specialize for that case.

[theme]

Filed an issue for making ExactSizeIterator unsafe

ExactSizeIterator should be an unsafe trait

[quantheory]

I’m not sure if this is sensible, but if not it might inspire someone to have a better idea:

unsafe trait ExactSizeIterator {}
trait MaybeExactSizeIterator {
    // Edit: The `&self` isn't actually used in the blanket impls, but it
    // seems necessary for object safety?
    fn size_hint_is_exact(&self) -> bool;
}
impl<T> MaybeExactSizeIterator for T where T: ExactSizeIterator {
    fn size_hint_is_exact(&self) -> bool { true }
}
impl<T> MaybeExactSizeIterator for T where T: !ExactSizeIterator {
    fn size_hint_is_exact(&self) -> bool { false }
}
trait Iterator : MaybeExactSizeIterator {
    // ...
}

Pros:

• Addresses this issue.
• Everyone who accepts an Iterator can get this information without loss of generality.
• unsafe is in the right place.

Cons:

• It makes no sense to implement ExactSizeIterator without also implementing Iterator, so the dependence is a bit weird.
• We have to have specialization that can get something like the above past the coherence rules. If you don’t have negative bounds of some sort, you unfortunately can’t express anything about the absence of an unsafe trait.

[nikomatsakis]

@tbu

It's even worse than I understood from that comment. The proposed method would be unsafe to call, but you can implement it without unsafe, with a simple fn exact_size(&self) -> bool { true }.

I just wanted to note that this is no longer true now that PR Move fn safety out of the subtyping relationship and into coercions by nikomatsakis · Pull Request #23452 · rust-lang/rust · GitHub has landed. If you have an unsafe fn in a trait, the impl must now implement it with an unsafe fn as well.

[huon]

Great! I think I’m pretty happy with the unsafe method solution now.