SE-0382: Expression Macros

[Douglas_Gregor]

@Douglas_Gregor

I'm going to backtrack a bit on my earlier enthusiasm for this change. Macros are so much more expression-like that allowing one to omit the () for macros, when it has a different behavior for functions, that introducing an inconsistency here feels worse than having macro authors decide between : and ->.

I'm flip-flopping here again. @Snowy1803 you are totally right, we should stick with -> and allow () to be omitted at the use site. The revisions to the proposal, linked below, include that change. Sorry for the too-quick responses.

@Douglas_Gregor

@s-k

I had the idea that the macro could add #sourceLocation() annotations to the expanded code.

We could add something like this, although I was thinking it would be an operation on the MacroExpansionContext that gives a source location for the syntax node it's passed.

This came up a lot, and I've begun to think that this proposal isn't sufficiently complete without the ability to get source location information for a syntax node. For example, the excellent "power asserts" macro depends on having this information. I've added an API for this (on MacroExpansionContext) in the mini re-pitch.

@kishikawakatsumi

I agree that tool-related topics are outside the scope of the language feature review, but I would like to know what kind of macro support is planned for Xcode, as we cannot know anything about Xcode.

Can't comment on what Xcode. However, I will point out that there is an expand macro refactoring in SourceKit now, which should be usable for any client of SourceKit-LSP, such as the VS Code Extension for Swift.

@benrimmington

Should createUniqueName() have an optional prefix / suffix / template parameter?

context.createUniqueName()            //-> `_unique1`
context.createUniqueName("maxValue")  //-> `_unique2_maxValue`

Yes, this is a good idea. I've pulled it into the mini re-pitch.

Doug