[swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Jean-Daniel]

> Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello,
>> 
>>> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
> 
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/b16b850e/attachment.html>