[Question] Overriding Display for Error Types?

[Zicklag]

I've got a quick question about the varlink generated error types. Take this generated code for example:

pub enum ErrorKind {
    Varlink_Error,
    VarlinkReply_Error,
    Error(Option<Error_Args>),
    HookFailed(Option<HookFailed_Args>),
}

I have two user-defined errors in my .varlink file: Error, and HookFailed. My question is, why are the error arguments inside of an Option? According to the varlink definition, the error must have the arguments that I have defined, so in what cases would the error Arguments be None? I'm mostly trying to figure out if a None value in this case should be a panic, or whether or not that can happen in normal operation.

[Zicklag]

As a related note, the reason I'm trying to figure this out is because I want to override the Display implementation of the Varlink errors. Right now I'm planning on using Regex to replace the existing display implementation with my own, but that seems hackish. Do you have any other ideas for a way to do this?

[Harald Hoyer]

Hmm, easiest thing would be a generator option specifying not to generate the Display trait.

[Zicklag]

The way I did it was I replaced the generated implementation with an include! so that it would include my implementation from another file. We could add an alternative_display_impl option that would be an Option<&Path> maybe.

[Philipp Gesang]

Hmm, easiest thing would be a generator option specifying not to generate the Display trait.

That would be useful for other traits too. I just tripped over the
PartialEq trait which I need to behave differently
(array should be treated as equivalent irrespective of the order
of elements) than the derived one.