[swift-evolution] General take on "special" code in Swift

[Chris Lattner]

> On Dec 3, 2015, at 11:21 PM, Timothy Wood <tjw at omnigroup.com> wrote:
> 
> 
> First off, thanks for all the hard work in putting together an in-depth release and open community infrastructure!
> 
> Looking through the Swift sources briefly, I’m noticing various constructs that aren’t documented, idiomatic Swift, or even Swift at all. This isn’t super surprising for various mostly obvious reasons. But, one particular example that caught my attention is in swift/util/gyb.py ("GYB: Generate Your Boilerplate”), and all the .gyb files scattered around.
> 
> One of the various Apple Swift tutorial/reference PDFs had the canonical maligning of the C preprocessor (warranted, but yet it is a powerful and useful tool), and yet here is the Swift standard library using a preprocessor of another sort.
> 
> For this specific case, I could ask for some magical hygienic macro support, with full debugger support, autocompletion, and puppies (which would be great!), but the more general question is whether the Swift team feels like this dichotomy is OK, or whether it just (a ton of) work that is left to do? Should it be the case that the standard library, Foundation, testing frameworks, and such are almost entirely idiomatic Swift code (even if they are using advanced features)?

This is a better question for swift-dev than swift-evolution, but…

IMO, “gyb” is a pragmatic but unfortunate tool.  It fills the same space as the underscored protocols in the standard library: it allows us to ship a product that is useful, but they are both far from ideal.  The _ protocols were generally forced by some limitations in the generics system and other parts of the compiler.  GYB is needed by those, but also by the fact that we don’t have a hygienic macro system (we certainly won’t have a macro system in Swift 3, but could consider it after that).

The good news is that the need for these things is being reduced as Swift improves.

-Chris