Add simpler macro versions of ULE/VarULE macros to reduce `syn` deps

[Manishearth]

See #2310

In #5124 we're trying to slim down ICU4X's deps. A lot of our crates don't need the full power of the ule/varule macros, and it would be nice to expose MBE macro versions of them.

[Manishearth]

There are a bunch of similar but distinct use cases for simple transparent wrappers.

• A wrapper ULE type that has a custom AsULE impl pointing to it but otherwise transparently wraps a u8 or something. e.g. SkeletonDataIndexULE. We need a way to generate passthrough ULE impls for this.
• A wrapper VarULE type that uses ref-cast like impls, e.g. NormalizedPropertyNameStr. We need a way to generate passtrhoguh ULE impls and ref-cast-like methods for this.
• A wrapper AsULE type that is transparent for unclear reasons: e.g. every property type. Do these actually need to be transparent? Can these just be AsULE? Either way, this can be handled with a non-wrapping macro that just does impl_passthrough_asule!(ULEType, AsULEType, AsULEWrappedType) or something.

Furthermore:

• make_ule on an enum is doable with a macro
• make_ule on a struct is super doable with a macro

[robertbastian]

How feasible is it to write zerovec-derive without syn? It'd still be more powerful than macro_rules.

[sffc]

I proposed one solution in #5101.

What other solutions might be considered?

[Manishearth]

@sffc I'm confused, this issue is proposing the other solution. It's listing out the macros that could potentially be written. I know how to write these macros. I'm not writing them yet because i want to figure out what the full gamut is before I start designing them. Is there something else you're looking for here?

How feasible is it to write zerovec-derive without syn? It'd still be more powerful than macro_rules.

It's ... really annoying I'd say. You'd end up implementing a half-baked parser..

Now, you could do something like implementing a macro that gets called as impl_wrapper_ule!(// docs go here, CanonicalCombiningClass, pub u8) as a proc macro, but at that point you can just do a regular macro just as easily.

Honestly, for the thing this issue is about, MBEs are quite sufficient. For things not listed in my comment above, I don't think a non-syn impl will be easier than MBE since MBEs actually let you implement a half-decent parser without writing an actual parser.

[Manishearth]

I'm also not prioritizing working on this: I don't perceive this issue as urgent compared to 2.0. Please let me know if you think this should be higher priority, happy to start looking at this properly, but so far I don't see any reason to rush this. It's good to document all of the fruit hanging at any height for #5124 so that we have an idea of potential wins, but I'm not yet convinced I should spend time on this vs 2.0 issues.

(and 2.0 diplomat still needs work)

[sffc]

@sffc I'm confused, this issue is proposing the other solution. It's listing out the macros that could potentially be written.

But I wrote these macros in the PR, and the way I wrote them was rejected.

Currently the issue is describing the use cases behind the macros I proposed without proposing a concrete alternative.

I know how to write these macros.

You've said this, but I don't know what's in your head, and what tradeoffs different ways of writing the macros could entail.

I'm also not prioritizing working on this: I don't perceive this issue as urgent compared to 2.0.

This issue is unlikely to ever be higher priority than milestone tasks, but we've (or at least I've) been wanting these macros for a long time and we keep incurring debt without them. I opened my PR when I did because I felt I could justify the work since I was expecting two more of these landing this week (DataKeyAttributes and PatternULE which is needed for units patterns). We also delayed the Pattern rewrite for a long time since it was never higher priority than milestone tasks.

[Manishearth]

Currently the issue is describing the use cases behind the macros I proposed without proposing a concrete alternative.

I don't want to actually put in the effort of writing these macros until the full set of use cases is enumerated. Making macros flexible is a lot of work, and it is ideal to come in understanding the full desired extent of flexibility.

And no, this is not describing the use cases behind the macros you proposed, it describes multiple others as well: you covered one of these use cases with that PR.

You've said this, but I don't know what's in your head, and what tradeoffs different ways of writing the macros could entail.

I don't see the point of going deep down implementation land until we know what we're hoping to cover. For that I need to look at the actual potential callsites.

What's in my head is more or less an understanding of what is possible with the macro system, it seems like you think I have a very specific implementation in mind? I have multiple ideas, and could implement it one way or the other, but I don't think we're there yet.

The hope is to not have any external difference: no new traits, no new per-crate unsafe code, just replacing a safe derive or make_ule with a safe wrapping macro invocation.

I believe I already put forth a rough sketch earlier in that thread, but here is what one such macro invocation can look like:

impl_wrapper_varule!(
 [cast: (cast_ref, cast_as_ref, cast_box, ..), ... other options .... ],

/// Docs
#[derive(..)]
pub struct FooWrapper(str);

);

and basically the macro applies the transparent for you.

Implementing the "options" will get tricky but not too tricky as long as you pick a good syntax. Handling pub/priv stuff will be annoying.

Highlighting that this is an example, the exact syntax and mechanisms are not yet something I've decided upon.

Happy to talk more about the design but it's still not clear to me what you want to know about it. I know enough to know that this is possible, but I can't have a more concrete design until I better understand all the use cases, which is precisely what I'm trying to do with this issue.

[Manishearth]

We also delayed the Pattern rewrite for a long time since it was never higher priority than milestone tasks.

Sure, but for me actually work on this before 2.0, some other 2.0 blocker work item is getting pushed back. Diplomat stuff is taking more time than expected so I'm trying to be careful with what I take on.

I'd rather schedule this as 2.x priority: to be fixed basically immediately after 2.0.

[Manishearth]

Unless there's a reason this will impact the 2.0 design in some way: which is not entirely out of the question! If we can break a bunch of dependency links, and maybe add some features, that's a valid reason to make a breaking change that enables that.

Which is another reason I want to understand the use cases first, so we can see which crates we can liberate here.

But also so far I don't see a reason for these macros to cause 2.0 breakages. If there are, do let me know.

(One potential one is if we discover that e.g. properties can be 100% no-proc-macro if we turn bidi/ccc/whatever into a feature flag. Though that particular one can still be done stably. There may be others like it)