So not sure if I'm the only person who'd be interested in this. But I was doing some work today where it would have been far cleaner, more fluid, and more readable in the source code to have something along the lines of:
func process(_ value: @autostring String) {
print(value)
}
process { Sometime in the future, there was a @autostring attribute
that acted like automatically placing a triple double quote around anything between the closure brackets
including new lines, double quotes, and other items. }
Which would be the same as value being equal to:
process("""
Sometime in the future, there was a @autostring attribute
that acted like automatically placing a triple double quote around anything between the closure brackets
including new lines, double quotes, and other items.
""")
It's kind of a niche request and it's quite possible I'm the only person who has a chunk of code that would be vastly more readable if it was possible to do this. But thought I'd throw it out to see if there's any interest at all.
This would likely tie parsing to name resolution and type checking in the compiler, adding complexity and dependencies between components that would likely translate into more crashes and instability.
My experience with this sort of thing (and it's visible even just here with the syntax highlighting), is that it makes code less readable, because it's much harder for both humans and tools to work out where things start and end. Additionally, it requires answering questions like: do we require that ()//{} are properly matched? This is required for source code, but not for human languages, and they do occur unmatched in practice :(. If no, that makes it really hard to work out where things end, and likely means there basically can't be a } in the text at all.
Could you say more about what you want this for? Maybe there's some other way to get what you want. :)
"Impossible" is too strong a word, but I think it's fair to say this would at least be "extremely difficult". The compiler can't know that process will end up matching an @autostring declaration until it's at least parsed and type-checked the expression it's in. By that point, it's too late.
@autoclosure works because the contents of an autoclosure parse correctly before the compiler knows that the parameter is an autoclosure; once it discovers that, the compiler simply scoops the fully-formed, valid expression out and wraps it in a closure. We could write a much more limited @autostring feature which required the expression to be syntactically valid Swift code, but other than extremely simple expressions like numeric literals and bare variable names, I'm having trouble thinking of anything you'd want it to stringify. A dual feature where you got both the result of the expression and the string form might be slightly more useful for logging, but it still seems pretty niche. Neither one would solve a use case anything like the one you show.
It’s very unlikely going to happen because the compiler pipeline would need significant reworking for the reasons stated above, and the compiler would probably be slower too. But I see two additional issues.
For one, text editors can’t provide syntax highlighting without doing a typecheck (and thus run the compiler). Current Swift has almost no such issues. Even @autoclosure works because an argument is just an expression like any other to a syntax highlighter. Support for text editors outside of Xcode is important, and IIRC the core team has expressed this desire in the past with some other proposals.
Second, it provides no real benefit beyond what single-line and multi-line literals provide. A third construct complicates the language and makes it harder for beginners to read code.
The cleanest solution to have long strings is still just putting it in a file and loading the file. It keeps the line count of the Swift file low and thus improves locality of code (important when reading). If the string has a syntax, it’s easier to use syntax highlighting on a file than in a string literal in a Swift file.
And that's all fair. As I said, I recognize it would be a niche request. Thanks for all the input though, I hadn't yet looked at how the tokenizer is actually implemented, so this clarifies that quite a bit.
