which would then be expanded.
I know that one of the design goals for macros has been to avoid this kind of invisible macro use, but there's already a lot of compiler magic with the expressible by _ literal protocols, and this would make them a lot more versatile.
For example, currently if your type is ExpressibleByStringLiteral but only some string literals are valid, your only choice is to trap at runtime if an invalid string literal is encountered. This defeats the compile-time nature of literals which should allow for checking of the literal. In the Foundation pitch for URL to be ExpressibleByStringLiteral this was an issue that was somewhat glossed over, but is totally solved with this.
anything weird happening with a string literal at compile time with a macro, can also happen today at runtime with an ordinary ExpressibleByStringLiteral conformance, just less safely and without the possibility of static diagnostics.
Wouldn't this immediately run into problems if two of these tried to turn the same type of literal into different types? Say something turn them into a URL and something else tries to turn them into an Image? I believe macros get resolved before the compiler can use the context to figure out what type it might actually need to be, and this seems like it would need some knowledge of the type the macro ends compiles to after expansion to properly pick the right one.
This is what I was asking about above–I thought macros got resolved where before types come into play. Don't these all work (today) via finding overloads/constructors to provide the accepted types? I thought macros got resolved before typing happened as types can change as a result of their expansion.
I should clarify - I think the compiler would have to know not only the type of the input, but also the type of the output to decide if the macro applies. With just the input type, it would have to apply all macros that worked on that input type and determine what the result types are. But in either case, it means the whole type resolution would then have to factor the macro applications into the mix on trying to decide what to do.
presumably we would use some sort of attribute hook the way we have done many times in the past with similarly shaped features. (@dynamicMemberLookup, result builders, property wrappers, etc.)
the way i always assumed macros-as-literal-parsers would work is that the macro would only serve to provide diagnostics and the actual parsing of the literal would remain the responsibility of the ExpressibleBy initializer witness.
it sounds like the issue there is the current macro implementation loses the syntax information after the source code has been typechecked. (not a compiler developer, so this might be completely wrong!) but i imagine there is a straightforward strategy here - preserve the syntax information (which is really just a string literal) until the diagnostic macros have gotten a chance to run.
I don't think it's unprecedented to let literals be "restricted" depending on the type context. We already have the protocols ExpressibleByGraphemeClusterLiteral and ExpressibleByUnicodeScalarLiteral which are just string literals that are restricted to one character or Unicode scalar respectively. With macros we can validate various other things at compile-time, such as string literals that are valid URLs, string literals with only ASCII characters, etc.
I think that's a really good point. Back in Swift 1 there was some adaptation required by the C-family folks to come to terms with there not being a distinction between string literals and character literals, but of course time has demonstrated that the sky has not fallen.
(I say that as one of those who's first impression was "oh no, that's a terrible design choice" and was wrong)
I was ambivalent on this proposal 'til now. Given this (and earlier) demonstrations of how we already have this "magical" behaviour, I don't think it's a significant concern - any moreso than things like operator overloading being supported; yes, it can be abused to make code hard to read, but the pragmatical solution to that is: don't do that.
And it allows pre-existing behavior to be expressed more cleanly. For example, in SwiftSyntax, you can create syntax nodes from a string literal. Now, that means that if you create invalid code, it will fail at runtime instead of compile-time. And, it adds this initializer:
which a misguided developer could use to avoid optional-chaining, while actually just (basically) force-unwrapping the value.
With the macro it would be much clearer what was going on and it would allow for compile-time checking.
It sees that the parameter takes a URL. So it tries to type-check the string literal as a URL. First it checks if URL is ExpressibleByStringLiteral and then it would just check if URL was ExpressibleByMacroStringLiteral. At least to me it doesn't seem like a significant departure from current behavior.