SE-0382 (second review): Expression Macros

[Douglas_Gregor]

@s-k

@Douglas_Gregor

I think the first one should be solved with a query function on MacroExpansionContext that provides access to the types of the various subexpressions. I think it's important that the way in which it represents types be coordinated with any work on reflection, so I don't want to lump that in with this proposal.

I wonder if a first version of this function could just return a token that can act as the type’s name in the generated code. I believe this could solve most of the problems I faced.

Yes, we could produce a TypeSyntax here (rather than some semantic notion of the type). I'm a little concerned that we'd be building an API that we'll throw away the moment we got some semantic notion of the type.

@rxwei

Should createUniqueName(_:) be named makeUniqueName(_:) instead to follow the "factory method" naming guideline ?

I'd forgotten about this guideline. I suppose makeUniqueName(_:) is better.

Doug

[s-k (Stephen Kockentiedt)]

@Douglas_Gregor

Yes, we could produce a TypeSyntax here (rather than some semantic notion of the type). I'm a little concerned that we'd be building an API that we'll throw away the moment we got some semantic notion of the type.

That would be really great! And I think that this functionality would be helpful even if semantic type information is also available at some point.

[xwu (Xiaodi Wu)]

Thank you all—again—for your participation in reviewing this feature. The proposal has been accepted as revised.

Xiaodi Wu
Review Manager