Revisiting the idea of meta-programming in Swift

Evolution Discussion
1

My understanding is that meta-programming a la C++ was rejected long time ago and is not a goal for Swift generics. I'm 100% on board with the rationale behind it, but I wonder if the community and core team would consider a different approach or this is a dead-end.

Meta-programming saves a lot of time. I've been using SwiftSyntax and plugins to save countless hours in writing and maintaining boilerplate. However, I think we can do better. And by better I mean easier to write and maintain and more accessible to everyone.

Now that we have ABI stability and SwiftSyntax is maturing nicely, would there be any interest in revisiting meta-programming in Swift?

I have a couple ideas, most of them revolving around a SwiftSyntax-inspired DSL that would constrain the output to be syntactically correct.

#meta
ImportDecl(pathBuilder: {
    AccessPathComponent(name: "SwiftUI")
})
ClassDecl( ... ) {
    MemberDeclList( ... )
}
#endmeta

The above is the current SwiftSyntax DSL, but it can be improved a lot in terms of usability.

There are lots of things I haven't fully considered yet, like sandboxed output, read access to the build dir, conditional declarations, loops, and so on, but I'd be happy to think about it and write a proposal, if we ever get to that.

2 Likes
2

Sorry, but what are you proposing? I'm not sure if I miss any crucial information given I don't use SwiftSyntax.

1 Like
3

@Lantua Not proposing anything just yet, just trying to bring this topic into light again.
The above would be a Swift DSL (similar with what SwiftSyntax has right now), inlined inside Swift source files, that would be expanded before compilation into Swift code. Something similar with Rust's macro_rules, except, perhaps more user friendly and using some of the tools and frameworks we already have. Hopefully that helps!

1 Like
4

As far as I understand it, the idea of meta programming, hygienic macros or something along those lines is not rejected. What is rejected is doing this too soon and causing people to start patching the holes that would be better addressed by completing existing features or adding to the expressive power of the base language so that you can define those as normal Swift library code without resorting to meta programming. (e.g. property wrappers)

So, the current focus is on completing the features of the core language. For example, completing generics feature set can help eliminate quite a bit of the boilerplate.

5 Likes
5

You're right that there is little to no enthusiasm here for template meta-programming as done in C++. However, there have been several attempts to discuss other meta-programming approaches, here's one from the language creator himself and the long forum thread that ensued four years ago.

More recently, there was a pitch by an Apple engineer that expressed interest in going in that direction again, though that first pitch was narrowly constrained to avoid the issue of compile-time evaluation for now.

I agree with you that Swift is lacking in this regard and while there seems to be community interest in adding meta-programming, we don't want to repeat the mistakes of past attempts in other languages. The new constexpr approach in C++ is a tacit admission that their prior compile-time approaches were a mistake.

I think you will have to wait till the follow-on pitches mentioned in that last link are proposed, to help push the language in this direction.

1 Like
6

In C++ defense, the use of templates for meta programming was an accidental addition to the language in the first place. Templates were originally just meant as a type safe replacement for certain patterns of C macros that turned out to also be capable of meta-programming.