Roland Fredenhagen

Thinking about it a bit more, I think the implicit behavior is fine, because `repr(u/i...)` can only be e specified on a field less enum, therefor `TryFrom` could not mean...

So I implemented this now, for now it just automatically does the repl, not sure if that is something that should be controlled by an attribute, but I cannot think...

We could also make the specific variant format availble via some variable name so you can use it via `{variant_fmt}` that would make the behavior clear and also support e.g....

I would prefere using an affix style fmt as it is more flexible than just prefix suffix and also more readable conserning white space etc., but I'd be open on...

Would you be able to access the enum variants values via e.g. `_0 - _1`? Could be useful for enums very every variant has the same format

@tyranron I agree with everything you said here. I'd also prefer default. One helpful error could be when you specify a non default fmt string and neither specify `self` nor...

> @ModProg > > > One helpful error could be when you specify a non default fmt string and neither specify `self` nor access `self` in any of the format...

> For the inexperienced user, it seems meaningful to provide default only when exceptions appear, and when there are none he wouldn't even think about default? That makes sense. And...

> And I think that single empty placeholder `{}` is clearer than `{self}`, because it would break our "exactly the same formatting, as `std::fmt`" assumption. But I'd argue that `#[display("Compound...

> Isn't `#[display("{self}")]` a recursive call? True. So maybe `variant`? But that would collide with a field called `variant`. Is there any use for a recursive Display? Atleast in the...