> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution > <[email protected]> wrote: > > Hello, > >> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution >> <[email protected]> wrote: > > [snip] > >> This is a huge undertaking, but if we split it in two parts: "executing at >> compiletime" and "exposing swift’s frontend”, this could surely be done by >> Swift 5. From all the ideas that I’ve had or seen on this mailing list, in >> my opinion this is the most ground-braking, powerful and useful, so I’d be >> willing to work day and night to help implement this. > > As you say, I agree that these are separate concepts (compile-time evaluation > vs. meta-programming), but the first is surely going to be helpful for the > second.
That’s exactly what I had in mind: compiletime execution comes first, meta-programming gets built on top of it. > As far as I can tell, compile-time evaluation would probably lose most / all > of the stdlib. I’d hate to replicate parts of the standard library in a > restricted subset of the language so that they are available in `constexpr` > mode (which is what 80% of C++’s template meta-programming libraries do). I’m > also not quite sure how to make that feature work with cross-compilation when > host and target differ in architecture. I disagree. Most of the standard library is in protocols and small generic wrapper structures, which are prime candidates for compile-time evaluation. Even if Foundation has to be dropped (which is actually not that big of a deal), I think adapting the standard library to be less architecturally dependent to make it accessible in compiletime wouldn’t be such a big problem considering that it is already largely driven by protocols. I think the architectural differences are negligible largely due to LLVM IR, which is portable (even byte ordering is taken into account). > As for the meta-programming / macro part, a recent C++ proposal tries to > extend the language in that direction: > https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf . > Ignoring the syntax, at the very least it might reduce the need for gyb in > places. That said, because Swift’s and C++’s instantiation model for generic > code is so different, there’s going to be some blockers there… C++ relies on its template system as a compile-time code generation mechanism to achieve this, that’s why it can get away with little-to-no metaprogramming concepts. The major drawback is that it’s a lot like the C preprocessor: it’s a dumb search-replace shtick that has to be micromanaged to work correctly. Since Swift’s generics are a whole different kind of fruit, they are more closely related to C++’s functions that take a polymorphic pointer, rather then a template function, so Swift’s generics are not going to be of any help in this. My idea was to introduce a first-class toolset to Swift that allows one to essentially generate arbitrary Swift code at compile-time, but rather than generating a string and mixing it into the source, it would be much more AST-aware and safe. This could be done by executing a function at compiletime that returns an instance of Meta.TypeDefinition, which would be declared as compiletime struct (meaning, that the type and its instances cannot exist at runtime). The import keyword could be reused to not only statically import modules, but to import instances of Meta.TypeDefinition. > So while I think they’re both great features to have, I assume the core team > will have higher priorities on their schedule, as I don’t see how these > features wouldn’t eat up most resources for at least (!) one Swift > release-cycle. That’s just it: the core team is already prioritizing a lot of features that would greatly benefit from this. In fact, if this would be implemented, a large portion of the swift compiler could be moved into the standard library, because it wouldn’t be magic any more. This would single-handedly reduce the implementation time and effort of most proposals by a very large margin. > Daniel. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
