Option to `impl Error` under feature flag

[jhpratt]

Right now, I have an enum for various error types. Display is in core, so that's implemented unconditionally. However, Error only exists in std, so I've put it behind a feature flag (named "std") to allow compatibility with #![no_std]. Having the ability to do this programmatically would be helpful for this use case.

Something like this would be workable, I think.

#[derive(Error)]
#[error_feature = "std"]
enum Foo { ... }

[dtolnay]

I would prefer not to build this into thiserror for now. The Display functionality is optional though, we won't emit a Display impl unless you provide #[error("...")] attributes. That means you can mix any other Display derive library with thiserror's Error derive:

#[derive(Display)] // maybe displaydoc crate, or display_derive, or derive_more
#[cfg_attr(feature = "std", derive(Error))]
enum Error {...}

[Robbepop]

The whole point of crates such as thiserror is to avoid boilerplaty code.
However, not having a builtin mechanism for such a common case such as crates that are (optionally) no_std completely destroys this point as far as I understood the problem.

So currently developers of such crates have to write something like this:

#[derive(Debug, Clone, PartialEq, Eq, Hash)]
#[cfg_attr(feature = "std", derive(Error))]
#[cfg_attr(not(feature = "std"), derive(display_derive::Display, derive_more::From))]
pub enum ExprError {
	#[cfg_attr(feature = "std", error("encountered error while casting"))]
	#[cfg_attr(not(feature = "std"), display(fmt = "encountered error while casting"))]
	CastError(#[cfg_attr(feature = "std", from)] CastError),
	#[cfg_attr(feature = "std", error("encountered error while type checking"))]
	#[cfg_attr(not(feature = "std"), display(fmt = "encountered error while type checking"))]
	TypeError(#[cfg_attr(feature = "std", from)] TypeError),
	#[cfg_attr(feature = "std", error("encountered error upon bitvec execution"))]
	#[cfg_attr(not(feature = "std"), display(fmt = "encountered error upon bitvec execution"))]
	BitvecError(#[cfg_attr(feature = "std", from)] BitvecError),
	#[cfg_attr(feature = "std", error("expression has too few children"))]
	#[cfg_attr(not(feature = "std"), display(fmt = "expression has too few children"))]
	TooFewChildren {
		expected_min: usize,
		actual_num: usize,
	},
	#[cfg_attr(feature = "std", error("symbol has unmatching type"))]
	#[cfg_attr(not(feature = "std"), display(fmt = "symbol has unmatching type"))]
	UnmatchingSymbolTypes {
		assoc_ty: Type,
		current_ty: Type,
		symbol: NamedSymbolId,
	},
}

Instead of simply:

#[derive(Debug, Clone, PartialEq, Eq, Hash, Error)]
pub enum ExprError {
	#[error("encountered error while casting")]
	CastError(#[from] CastError),
	#[error("encountered error while type checking")]
	TypeError(#[from] TypeError),
	#[error("encountered error upon bitvec execution")]
	BitvecError(#[from] BitvecError),
	#[error("expression has too few children")]
	TooFewChildren {
		expected_min: usize,
		actual_num: usize,
	},
	#[error("symbol has unmatching type")]
	UnmatchingSymbolTypes {
		assoc_ty: Type,
		current_ty: Type,
		symbol: NamedSymbolId,
	},
}

Which would completely eliminate the avoidance of boilerplate code.
Of course I exaggerated a bit with this example by using thiserror's Display derive functionality additionally. On the other side, why would I want to introduce another whole dependency if I can also avoid it? Especially for bigger projects it is important to avoid having too many dependencies.

If that's the case and if I am not completely mistaken by this in some way this is kind of a non-starter for my crates sadly ...

@dtolnay Can you please reconsider this? Because besides this your crate is perfect.