Either over enums: which one is better?

[drHuangMHT]

I've been writing some macros to help compose connection handlers like these. Reason? Those binary-tree-like nested Eithers are driving me crazy! The code seems to pass type checks but I'm not sure how well it works. Before digging deeper and deeper into macros, I have a question to ask: which one is better, generated nested Either or generated enums that bundles everything together? In my opinion, enums are much more intuitive, at least to me. And they are much easier to manage when you want to manually combine NetworkBehaviours(or really, ConnectionHandler). So, will there be one day we kick nested Either out of our code?

[thomaseizinger]

My vision for this is to push forward on #3591. That will remove the Error type from ConnectionHandler and simply make that 2nd type parameter on SwarmEvent go away completely :)

[drHuangMHT]

Are you aware of the NetworkBehaviour custom derive? It does all of the code-generation for you. You can use it by putting #[derive(NetworkBehaviour)] on a struct that contains multiple other behaviours.

Of course I am, it's right above line 21 and the derive macro will work just fine. You can't possibly miss that though?

[thomaseizinger]

Are you aware of the NetworkBehaviour custom derive? It does all of the code-generation for you. You can use it by putting #[derive(NetworkBehaviour)] on a struct that contains multiple other behaviours.

Of course I am, it's right above line 21 and the derive macro will work just fine.

Is there a reason you don't want to use it then? Or why go through the pain of writing macro_rules instead?

[drHuangMHT]

Of course I am, it's right above line 21 and the derive macro will work just fine.

Is there a reason you don't want to use it then? Or why go through the pain of writing macro_rules instead?

I don't have answer to that yet. But back to the question I raised for this discussion, is a nested generic either-like type better than dedicated enumeration? I will say yes because it is a very well defined interface, but as the number of items grows it becomes harder to maintain, at least in my mind.

[thomaseizinger]

Of course I am, it's right above line 21 and the derive macro will work just fine.

Is there a reason you don't want to use it then? Or why go through the pain of writing macro_rules instead?

I don't have answer to that yet. But back to the question I raised for this discussion, is a nested generic either-like type better than dedicated enumeration? I will say yes because it is a very well defined interface, but as the number of items grows it becomes harder to maintain, at least in my mind.

Another important aspect is that a type-based composition approach (at least for low-level components) is preferable because it doesn't need macros. ConnectionHandlerSelect is just regular Rust.

When done well, this doesn't surface to the user. Currently it leaks to the user through the SwarmEvent as described above.

Whenever you generate code, it should ideally be something that the user never interacts with (like the Serialize impl of serde).

That is an aspect of our solution that I don't like. The user needs to interact with an enum that they can't see.

[drHuangMHT]

Another important aspect is that a type-based composition approach (at least for low-level components) is preferable because it doesn't need macros. ConnectionHandlerSelect is just regular Rust.

That makes sense. Case closed for now.

When done well, this doesn't surface to the user. Currently it leaks to the user through the SwarmEvent as described above.

That's indeed a major concern because it is so annoying that I have to make a type alias.