Hello, > On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution > <swift-evolution@swift.org> 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. 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. 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… 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. Daniel. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
