Now that alloc is stable, this is a somewhat visible omission from no_std contexts.

In practice, it being in std means that library crates that would otherwise be no_std (+ alloc) compatible which expose some sort of error type have to either:

1. Skip implementing std::error::Error for their error type, giving up error ergonomics for users regardless of whether or not they care about no_std
2. Hide the implementation of std::error::Error behind a feature, which is awkward.
   • And if you already have alloc behind a feature, now you end up with separate alloc and std features (which is the option I took in one of my crates, and is mostly why I'm filing this) but is tedious, and makes your library have a larger configuration surface than feels necessary.
3. Ignore no_std completely (what most crates do and will probably continue to do).

Bummers, all of them.

If Error is moved to alloc, while not ideal ^[1], it would make things easier for the relatively common case of library crates that could otherwise be no_std + alloc, but don't want to give up error handling ergonomics.

[1]: I think having Error in core makes more sense, but IIUC it can't: #33149 (my read of this, which is probably wrong in some way, is that it's more or less because Error::downcast needs to be able to return a Box<T>)

As far as I know nothing prevents it from being in alloc (since Box is present in alloc), but I could easily be missing something important.

anyway thx for coming to my ted talk