Support for structs

Are you planning to add support for plain structs, rather than just enums?

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

@alexreg, you also need a syntax for tuple structs

Talking about syntax, it would be nice to require (or at least accept) commas after blocks for each enum variant.

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.

@alexreg

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?

On 6 Jul 2016, at 21:36, Paul Colomiets notifications@github.com wrote:

@alexreg https://github.com/alexreg, you also need a syntax for tuple structs

Talking about syntax, it would be nice to require (or at least accept) commas after blocks for each enum variant.

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #25 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAEF3I81Bd67YTD_ir8Jaqo_ILMwluIjks5qTBHBgaJpZM4JD9F0.

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.

On 6 Jul 2016, at 22:42, Paul Colomiets notifications@github.com wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #25 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAEF3Fd7Bq5eR_0dvoEE6Cb9a5E7FDFEks5qTCFQgaJpZM4JD9F0.

By the way, generic enum types aren't currently supported, are they?

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? :)

On 10 Jul 2016, at 02:23, Paul Colomiets notifications@github.com wrote:

By the way, generic enum types aren't currently supported, are they?

No, because it's hard to implement with current macro system.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #25 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAEF3Atpju9znpg_3X6b1IELHoonLBYyks5qUEmigaJpZM4JD9F0.

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...

On 10 Jul 2016, at 15:08, Paul Colomiets notifications@github.com wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #25 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAEF3I5lzXXeAlyzlLMYNQvNRnElI8i_ks5qUPzQgaJpZM4JD9F0.

Navigation Menu

Repository navigation

Support for structs #25

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Support for structs #25

Description

Activity

tailhook commented on Jul 4, 2016

alexreg commented on Jul 6, 2016

tailhook commented on Jul 6, 2016

alexreg commented on Jul 6, 2016

tailhook commented on Jul 6, 2016

alexreg commented on Jul 6, 2016

alexreg commented on Jul 9, 2016

tailhook commented on Jul 10, 2016

alexreg commented on Jul 10, 2016

tailhook commented on Jul 10, 2016

alexreg commented on Jul 10, 2016

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions