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

[John McCall]

> On Aug 6, 2017, at 11:59 PM, Daryle Walker <darylew at mac.com> wrote:
>> On Aug 1, 2017, at 2:58 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> 
>>> On Aug 1, 2017, at 9:53 AM, Daryle Walker <darylew at mac.com <mailto:darylew at mac.com>> wrote:
>>> 
>>>> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan <gor.f.gyolchanyan at icloud.com <mailto:gor.f.gyolchanyan at icloud.com>> wrote:
>>>> 
>>>> Well, yeah, knowing its size statically is not a requirement, but having a guarantee of in-place allocation is. As long as non-escaped local fixed-size arrays live on the stack, I'm happy. 🙂
>>> 
>>> I was neutral on this, but after waking up I realized a problem. I want to use the LLVM type primitives to implement fixed-size arrays. Doing a run-time determination of layout and implementing it with alloca forfeits that (AFAIK). Unless the Swift run-time library comes with LLVM (which I doubt). Which means we do need compile-time constants after all.
>> 
>> We are not going to design the Swift language around the goal of producing exact LLVM IR sequences.  If you can't phrase this in real terms, it is irrelevant.
> 
> It isn’t being LLVM-specific, but for any similar system. The instruction generator has certain primitives, like 16-bit integers or 32-bit floats. LLVM (and probably rivals) also has aggregate primitives, heterogenous and homogenous (and the latter as standard and vector-unit). I want to use those primitives when possible. Saving sizing allocations until run-time, after it’s too late for sized-array-specific generated instructions, means that the array is probably implemented with general buffer pointer and length instructions. Any opportunities for IR-level optimization of the types is gone.

> How often do you expect a statically sized array to need said size determined at run-time (with a function) versus a compile-time specification (with an integer literal or “constexpr” expression)? This may enable a 1% solution that anti-optimizes the 99% case.

If the array type is ultimately written with a constant bound, it will reliably end up having a constant static size for the same reason that (Either<Int?, String>, Float) has a constant static size despite tuples, optionals, and Either all being generic types: the compiler automatically does this sort of deep substitution when it's computing type layouts.

Now, a generic method on all bounded array types would not know the size of 'self', for two reasons: it wouldn't know the bound, and it wouldn't know the layout of the element type.  But of course we do have optimizations to generate specialized implementations of generic functions, and the specialized implementation would obviously be able to compute a static size of 'self' again.  Moreover, a language design which required bounds to always be constant would only help this situation in an essentially trivial way: by outlawing such a method from being defined in the first place.

John.

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