Draft RFC: default types for traits

[canndrew]

@H2CO3

Ouch. First of all, since Default::default() isn’t const , this is allowed, however “perverse” one imagines it to be. Therefore, assuming it’s not the case would be incorrect.

But it doesn’t need to be a “perverse” thing either. A perfectly fine use case is a default-constructed RAII guard, for example. That would be impossible to rely on if this RFC was realized.

Can you give an example of an RAII guard that would be created using Default::default()? I mean, hypothetically someone might do this but I think @Nemo157 is right in pointing out that it would be weird to not at least write MyIoPerformingGuard::default() (or more likely MyIoPerformingGuard::new(and_probably_some_argument_that_says_what_we_are_guarding))

Nonetheless, I'll concede that including default Default = () might be a bad idea - at least if it got used without raising a warning - though I think in practice it would be unlikely to cause problems.

@HeroicKatora

Should Vec<_> be chosen as the canonical trait instantiation even when IntoIterator is not given?

I would say definitely not. If we only have a bound of FromIterator<B> and not IntoIterator<Item = B> then the type we need is one that collects values but never hands them back. () might make sense in this case if it implemented FromIterator<B>, although it's not clear whether the code expects the iterator to be drained or not (which is why () doesn't implement FromIterator<Item = B>). Once you add the IntoIterator<Item = B> bound though, you now need a type which consumes a sequence of Bs and then produces a sequence of Bs.

@scottmcm

How does semver work for these? If the first one existed, would it mean we could never add the latter, as it would change types?

That's a good point, though in this case NeverOutput<T> doesn't implement Default so it would be fine. Maybe @HeroicKatora is right and we shouldn't be able to override less-specific default type declarations with more specific ones.

@joelgallant

This is just my 2 cents as somebody new-ish to writing rust full time, but I’m highly in favor of something that would fix the -> impl Future { unimplemented!(); } problem.

Yeah that is one of the main motivations of the RFC. An alternative solution would be if we somehow had !: Future<Output = T> for all T. Perhaps ! should be more magical and automatically implement (almost) all traits. Or perhaps there should be a way of writing trait impls which turn associated types into generic type arguments, something like:

// T not used on Future or !, just on the associated type.
impl<T> Future for ! {
    type Output = T;
    ...
}

Writing <! as Future>::Output would then produce a type variable, unifiable with anything. I don't know whether this completely breaks the type system though.