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

[Chris Lattner]

> On Aug 1, 2017, at 3:36 PM, Jean-Daniel via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.

If you’re claiming that there is no way to express the natural pointer size of the machine, then that’s factually incorrect.  This will compute the target-specific size of %T (even if it is a pointer):
	getelementptr %T* null, i64 1

The problems major problems are with C though: sizeof(long) is itself a huge can of worms, consider LP64 vs LLP64 architectures, as one simple example.  C has a preprocessor that exposes machine parameters too early, and many other problems exist.  AFAIK, these issues aren’t exposed by Swift, except via the Builtin module and imported C APIs & types.

-Chris

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