Add details on the propagation of enum impl Trait

[robinmoussu]

Accessing the concrete types of enum impl Trait is extremely valuable when manipulating enum impl Error. To not fall in the same trap than checked exception, it should be possible to access them, even if those types are not visible in the API.

[Jon-Davis]

I am not fully aware of how the rust compiler works, and I do understand the need to ensure that the compile times are not exploding at the use of this feature. But I think this analysis won't be that bad. The types will need to be resolved by the compiler anyways so that the size of the object is known and the stack pointer is incremented accordingly. I think it would be ok to allow the use of the feature even across crate boundaries.

I also don't think having an exhaustive match is required, I would be ok making enum impl trait non exhaustive, this also gives library authors a bit more freedom to create new features that may return additional classes of errors without causing their user's code to break.

The feature should be opaque to the function header, but the user should be able to simply use it like it was declared transparently with the non exhaustive attribute. I don't think requiring a coercion is necessary.

I even think that the documentation should specify the non anonymous variants and their indices.

// function header
fn read_int_from_file() -> Result<i32, enum impl Error>
// Documentation header
fn read_int_from_file() -> Result<i32, enum(io::Error, ParseIntError, AnynomousClosure, ...) impl Error>

I also like the idea of being able to specify specific Errors to be returned, Especially in trait methods, It could enforce that a particular error is always supported and safe to match on in generic code.

[robinmoussu]

This PR should be rejected. @H2CO3 explains it in details in this post of IRLO. I keep it open to be able to continue the discussion.

EDIT: or maybe not!