Hacker News Reader

Comment by xg15 | Hacker News Reader

> After this change (and on the 2024 edition), the compiler assumes that T should be !, which doesn't implement Default, and therefore causes a compilation error.

If ! can coerce to every type, why not treat it as if it implemented every trait too?

View on HN

The Default trait provides a function that actually constructs the type in question. But here the ! type can never be constructed, so the only way to implement Default would be to have it panic, loop infinitely, or otherwise fail at runtime.

So this would risk turning a compile-time error into a runtime error.

Moreover, Rust traits' associated constants/types get in the way of having a proper bottom type. What would <! as Iterator>::Item be? (In Scala I think it just doesn't compile?)

Not only that, if you have `trait Foo: Iterator<Item = u8>` and `trait Bar: Iterator<Item = i32>` how could `!` implement both of them? It would simply make the language incoherent.

> What would <! as Iterator>::Item be?

Another ! makes sense to me here. Are there any cases where it doesn't work to auto-assign ! to all associated types of a ! trait impl? Associated constants might require some mechanism similar to `compile_error!()`.

Ah, that makes sense. Rust noob here, so I wasn't aware traits can act on types directly without any instance of the type. Thanks for the info!

Yep, they can have static methods, as it were (in Rust lingo called "associated functions"; "methods" in Rust always take a `self` receiver). Traits can also have associated types and associated constants, which (naturally) also relate to the type, not any particular instance.

Reply on news.ycombinator.com