Needs decision: should `Error` inherit from `Send`?

[aturon]

The Error trait was recently changed, once again, to inherit from Send. This was done mostly because

1. We suspect that many people will wind up using Box<Error>, especially once Error incorporated downcasting,
2. We worried that, after setting up such APIs, people would end up wanting to send Box<Error> between threads and not be able to, and,
3. We suspected that most errors would or could be made Send anyway.

However, there are some cases in important libraries like Iron that involve non-Send errors, at least at the moment.

We need to make a final decision here. Should we instead require people to know about and use Box<Error + Send> when they need it?

[aturon]

cc @reem @acrichto @nikomatsakis

[reem]

cc @alexcrichton :)

[reem]

@aturon note that this is blocking iron from building, so a swift decision would be quite appreciated

[nikomatsakis]

My feeling, as summarized to @aturon over IRC: better to be more general. If it turns out that people forget the Send a lot (and they probably will), we can always introduce an alias or something for Error+Send, and converting from Error to Error+Send ought to... mostly be compatible.

[Manishearth]

Does anyone think this needs an RfC? Though I believe the original Error RfC doesn't mention the Send bound so perhaps it's okay.

[aturon]

@Manishearth Yeah, I would consider this a relatively minor implementation detail. It's gone back and forth a few times since the original reform. I'm personally OK changing it a final time without an RFC.