-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for structs #25
Comments
I have no specific plans.And I think it might be useful. So pull requests are accepted. I'm not sure what syntax should be, though. So we can probably bikeshed on the syntax here. |
I'm glad to hear that. What about something like the following? It may not be ideal, but it's a possibility at least. (Perhaps I've missed an obvious issue with structs, so excuse me...) quick_error! {
#[derive(Debug)]
pub struct SystemError {
pub code: u32,
pub message: String,
pub inner: Option<Error>,
{
cause(inner)
display("error {}: {}", code, message)
description("io error {}", code)
from(e: u32) -> {
code: e,
message: get_sys_err_msg(e),
inner: None,
}
}
}
} Talking about syntax, it would be nice to require (or at least accept) commas after blocks for each enum variant. |
@alexreg, you also need a syntax for tuple structs
Yes, but in a macro, we don't have nice error reporting. So errors like missing comma are displayed in a very ugly way. So it was observed that without them there are fewer errors. |
Hmm okay, that’s a shame. Would be nice to have a feature maybe that required the comma (but by default without them, no comma). Just a thought. Tuple-structs could be a problem yes… what about the following, though? pub struct FooError {
fields…
} {
quick-error stuff...
}
pub struct BarError(...) {
quick-error stuff...
} Possibly with a keyword in-between the two scopes?
|
Yes. Looks good enough for me. I'm not sure what keyword can be there, and we don't have a keyword after the struct enum member. |
Right. You’d probably want a keyword after enum members too in that case… but having no keyword for anything might be fine.
|
By the way, generic enum types aren't currently supported, are they? |
No, because it's hard to implement with current macro system. |
I talked with some people on IRC about this, and it seems that an imperfect implementation is doable at least. Could we at least aim for a “bad” temporary solution? :)
|
You are talking about the generics, right? (this is a wrong issue) I'm probably okay with a contribution, if it will not double the size of the macro or something like that. But I'm not sure if I can find some time for that myself. |
I am, yes. And sorry to sidetrack. Maybe I’ll have a go, but the current code is basically magic heh. Perhaps a syntax extension/custom derive is the way to go for the future...
|
Are you planning to add support for plain structs, rather than just enums?
The text was updated successfully, but these errors were encountered: