Support for structs

[alexreg]

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

[tailhook]

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.

[alexreg]

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.

[tailhook]

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

[tailhook]

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.

[alexreg]

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.

[alexreg]

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

[tailhook]

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

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

[alexreg]

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.

[tailhook]

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.

[alexreg]

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.