lunatic-rs icon indicating copy to clipboard operation
lunatic-rs copied to clipboard

Mailbox should be the first argument in `spawn` and `spawn_link`

Open tqwewe opened this issue 2 years ago • 5 comments

The Mailbox prameter in the spawn and spawn_link functions is expected to be the last parameter.

I think it might make more sense for it to be first, since it's always required? Similar to how typically optional/default arguments are placed last in many languages, similar to the type definition of Mailbox<T, S = Bincode>, with T being required, and S being optional.

I think a side effect of this, would be that the spawn! and spawn_link! macros could accept multiple captured variables. Currently they only support one, but it could be many:

spawn!(|mailbox: Mailbox<String>, cap1, cap2, cap3| { ... })

With mailbox being last, I don't think this is really possible.

It's a pretty minor change, and would be a breaking change sadly, but I thought I'd open an issue anyway.

tqwewe avatar Aug 14 '22 11:08 tqwewe

Yes, I stumbled upon the same problem, trying to pass cap1, cap2 etc. before mailbox. But why isn't it possible to define a macro that handles mailbox being last? And what about mixing captured variables, variables defined during invocation, and mailbox: in what order?

ianxek avatar Aug 15 '22 11:08 ianxek

If you try this example (with mailbox last):

macro_rules! spawn {
    ( $( $captures:expr ),*, $mailbox:expr ) => {};
}

spawn!(1, 2, 3);

It has an error:

local ambiguity when calling macro spawn: multiple parsing options: built-in NTs expr ('mailbox') or expr ('captures').

But switching captures and mailbox around, it works just fine. There may be a way to solve this while keeping mailbox last, but the most simplest solution I think is to just swap them.

tqwewe avatar Aug 15 '22 11:08 tqwewe

Sorry, I completely forgot to come back to this.

The reason why it's the last argument is to stay consistent with Process::spawn().

I'm not completely against changing this. Ideally, I would like Process::spawn to take a variable number of arguments, but this just can't be expressed because of limitations in Rust :(

bkolobara avatar Aug 31 '22 10:08 bkolobara

Ideally, I would like Process::spawn to take a variable number of arguments, but this just can't be expressed because of limitations in Rust

Can we not do something similar to submillisecond, where we implement a trait for a function?

impl<M, A, B, C> SpawnFn<M, (A, B, C)> for fn(Mailbox<M>, A, B, C)
where
    M: Serialize,
    A: Serialize,
    B: Serialize,
    C: Serialize,
{ ... }

tqwewe avatar Sep 06 '22 04:09 tqwewe

Can we not do something similar to submillisecond, where we implement a trait for a function?

Not without forcing everyone to write spawn(my_func as fn(_, _, _, _)) (we do the this for users in the router! macro automatically)

bkolobara avatar Sep 08 '22 07:09 bkolobara