3 ms·

I also think Swift is getting bloated (and this can be seen in the compile times which are getting out of hand). Sometimes I feel like some features of Swift ha

by dadoum 2y ago

I also think Swift is getting bloated (and this can be seen in the compile times which are getting out of hand). Sometimes I feel like some features of Swift have been implemented without being well thought about, just because they are popular in the programming crowd. I am thinking more specifically about metaprogramming, which was originally a non goal, but I guess with time they saw it has a point and they replicated Rust's approach with syntactic macros which is to me a very poor approach. You need to much boilerplate to write a macro since it's a compiler plugin basically, and you can't interpret the semantic of the underlying code without reimplementing part of compiler's logic. I can find other examples, and that's not always bad, but I am not sure that's the right way of designing a language.

jarjoura 2y ago
I still have no idea where macros fit into a project, or why I would want to use them. They seemingly built this functionality for SwiftUI previews maybe?! and didn't really consider how this could be a core part of the language. At least with rust, you can just lightly add them in the same module and at a minimum use them to avoid boilerplate code duplication. Macros in rust work as a core language feature because of the way the borrow checker works. You can't really break apart some methods since you need to establish ownership. So, you can easily end up with duplicated code that gets noisy. Macros are the escape hatch to do that, and yes, they are also complex to write, but at least I know when I'd want to use them. Swift doesn't really document how to create macros, and they didn't really spend energy explaining how they would be valuable to a project and worth the engineering cost of implementing them.
- pjmlp 2y ago
  They fit into the same way as C, C++, Lisp, Scheme, Rust, Scala... macros, Java and Kotlin compiler plugins, .NET code generators, do fit into a project. There are several WWDC sessions about how and why.
- jen20 2y ago
  https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/ https://docs.swift.org/swift-book/documentation/the-swift-pr... seems to do both to me?
dwaite 2y ago
Macros were an early Swift goal, but were not the highest priority or a small amount of work that could be tackled as part of meeting higher priority goals. As an example - one could argue property wrappers exist because they were needed before macros could get done, and their syntax was chosen to align with where the Swift core team thought macros would land in the future.

by dadoum 2y ago

jarjoura 2y ago

I still have no idea where macros fit into a project, or why I would want to use them. They seemingly built this functionality for SwiftUI previews maybe?! and didn't really consider how this could be a core part of the language. At least with rust, you can just lightly add them in the same module and at a minimum use them to avoid boilerplate code duplication. Macros in rust work as a core language feature because of the way the borrow checker works. You can't really break apart some methods since you need to establish ownership. So, you can easily end up with duplicated code that gets noisy. Macros are the escape hatch to do that, and yes, they are also complex to write, but at least I know when I'd want to use them. Swift doesn't really document how to create macros, and they didn't really spend energy explaining how they would be valuable to a project and worth the engineering cost of implementing them.

pjmlp 2y ago
They fit into the same way as C, C++, Lisp, Scheme, Rust, Scala... macros, Java and Kotlin compiler plugins, .NET code generators, do fit into a project. There are several WWDC sessions about how and why.
jen20 2y ago
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/ https://docs.swift.org/swift-book/documentation/the-swift-pr... seems to do both to me?

dwaite 2y ago

Macros were an early Swift goal, but were not the highest priority or a small amount of work that could be tackled as part of meeting higher priority goals. As an example - one could argue property wrappers exist because they were needed before macros could get done, and their syntax was chosen to align with where the Swift core team thought macros would land in the future.