> On Aug 1, 2017, at 3:36 PM, Jean-Daniel via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
