jameysharp requested alexcrichton for a review on PR #4217.
jameysharp opened PR #4217 from component-tuple-refactor
to main
:
These helper functions are also useful for implementing this trait on user-defined record and tuple types.
jameysharp updated PR #4217 from component-tuple-refactor
to main
.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
I think this probably won't be reused externally because it specifically matches the
Tuple
type, right?
alexcrichton submitted PR review.
jameysharp submitted PR review.
jameysharp created PR review comment:
I think the wasm tuple type is the right thing for tuple-like structs and enum variants, so I'm expecting to use it for those. Does that seem right?
alexcrichton submitted PR review.
alexcrichton created PR review comment:
In that you're mapping
struct Foo(u32, u32)
totuple<u32, u32>
in the component model? For that I'd probably just return an error on a struct looking like that since that's already exposed as tuples and there's not really much need to expose a different way to name tuples in Rust.For enum variants are you supporting
enum Foo { A(u32, u32) }
? If so personally I'd prefer to reject that for now and stay strict in the derive to stay close to the component model representation if we can.Depending how the whole ecosystem shakes out we can revisit in the future and add "sugar" if this sort of type structure ends up being common in wit
jameysharp created PR review comment:
Huh, I see. Sure, I can do it that way.
I still want to factor this function out of the
impl_component_ty_for_tuples
macro, even if it isn't public. It's very similar to the typechecking function for unions, and with the addition of names, both of those resemble the typechecking functions for records, enums, and variants. I think it'll be helpful to keep them all next to each other.I've verified that rustc generates the same code on x86-64 release builds after refactoring the impl for tuples this way. (It inlines the helper function and unrolls the iterator, so the recursive typechecking calls are all direct.) So it seems to me that the main consideration here is whether the refactoring is easier to understand, and for me, getting code out of macros helps a lot in my ability to understand it.
jameysharp submitted PR review.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Ok that seems reasonable to me yeah. In general we don't have to worry too much about type-checking performance since that's typically front-loaded where possible off the critical path so it's ok to drop
#[inline]
on functions like this and otherwise just optimize it later if we really need to.
jameysharp updated PR #4217 from component-tuple-refactor
to main
.
jameysharp submitted PR review.
jameysharp created PR review comment:
Okay, I fixed
typecheck_tuple
to not bepub
. Thanks for your review! Anything else blocking this from merge?
jameysharp merged PR #4217.
Last updated: Nov 22 2024 at 16:03 UTC