[Feat]: Add default types for `Either` variants, as well as adding `OneOfExt` trait on `impl View`

[jquesada2016]

Is your feature request related to a problem? Please describe.

Currently, when returning different views from, say a match expression, we must use EitherOfN enum to unify the types. This absolutely works, but I think we can make it a bit better.

The roughness I've encountered is one with the following workflow:

1. I start with the following enum:

enum Example {
  A,
  B,
}

2. I start with a match:

match ex {
  Example::A => Either::A(view_1),
  Example::B => Either::B(view_2),
}

3. I add a new variant:

enum Example {
  A,
  B,
  C,
}

4. ...now I have to update my imports to use EitherOf3 rather than `EitherOf2``
   and I try the following:

match ex {
  Example::A => EitherOf3::A(view_1),
  Example::B => EitherOf3::A(view_2),
  Example::C => todo!(),
}

5. ...which of course won't compile because EitherOf3 is missing a type annotation.

To get around this specific issue, we can add a default generic type of () to all the Either enums.

Now, this would definitly improve the todo!() issue I often run into, but it still doesn't help that in all my match arms, I need to either wrap the view! {} in an Either directly, or assign the view to a variable and return it wrapped in an Either variant. This is quite frankly annoyingggggg.

I propose introducing a new enum, called OneOf that should have an arbitrarily large number of variants, say 128, with all default generics set to () as well as introducing an IntoOneOf trait that can be added to any view to wrap it in postfix notation.

Example:

enum OneOf<_0 = (), _1 = (), _2 = (), _3, /* ... */ _127 = ()> {
  A(_0),
  B(_1),
  C(_2),
  D(_3),
  /* ... */
  DX(_127),
}

trait IntoOneOf</* ... */> {
  fn a(self, a: _1) -> OneOf</* ... */>;
  fn b(self, b: _2) -> OneOf</* ... */>;
  /* ... */
  fn dx(self, dx: _127: _127) -> OneOf</* ... */>;
}

impl</* ... */> IntoOneOf</* ... */> for V
where 
  // Only ristrict V here so users don't get intellisense where it's not applicable.
  V: IntoView,
{
  /* ... */
}

Given this, the above match arm can be written as:

match ex {
  Example::A => view_2.a(),
  Example::B => view_2.b(),
  Example::C => todo!(),
}

The above should compile just fine.

To be honest, after writing this, I definitely wouldn't name the functions a(), b(), etc. Perhaps .one_of_a(), or .into_one_of_a().

Also, the reason for using OneOf with a large number of variants is just to avoid needing to import a different EitherN enum for the respective cardinality I need. This also would not replace Either, as it's still very useful for matching on a specific number of children, or similar. I just think this would be a bit nicer DX.

Let me know what you think!

Describe the solution you'd like

Lol I always struggle to seperate my problems from my solutions. Please see above.

Describe alternatives you've considered

The alternative would be to stick to using the any view extension function, at the cost of the fancy dandy view types used currently.

Additional context

N/A

[gbj]

You may also find the either macro useful in the context of "I'm adding a branch and have to rename things."

I am not familiar enough with the use of default generics on enums to know how this would affect things like compile times. One of the primary causes of some of our compile-time meltdowns on larger projects in 0.7 or so was (as I understand it) the exponential increase in compile times caused by deeply nested, many-branch enums... in part due to the very long type names the compiler would generate for them.

[jquesada2016]

The either macro won't work for me because I avoid using rustfmt-breaking macros like the plague.

I do also recognize why this would be an issue on compile times. What I could propose as an alternative to including it as a provided type in the leptos prelude, how about having the ability to create it via a provided proc macro? This way users could tailor it to their specific project.

Something like:

generate_one_of_n!(25);

The biggest downside of the above would be that it would no longer be a simple leptos::prelude::* import, but it would also not incur a universally arbitrary compile-time cost on each invocation, if we set it to, for example, 70 for the generics, rather be a user-specified cost.

Obviously, I'm guessing this is more of a me pet pieve, and thus I'll probably just implement it in user land. But it was worth throwing it out there. :)

Regarding compile times on generics with default types, I also don't know, but I wouldn't expect it to be higher than without including them, but I could see a scenario where the compiler needing to keep track of when to/not-to apply default types could incur a compile-time performance hit. Do we have a large project to benchmark against?

Edit:
I do have a substantially large project running on leptos, but it's on v0.4, and upgrading it to latest would probably land me divorce papers with my wife lol