> Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution > <[email protected]> a écrit : > >> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hello, >> >>> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution >>> <[email protected] <mailto:[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).
Why this long due myth subsist, LLVM IR is not portable. You can produce portable IR by limiting the scope of the input language, but it does not even provides a way to express sizeof(long) in a architecture independent way. And I don’t even mention the type layouts.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
