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

[Xiaodi Wu]

On Mon, Jul 31, 2017 at 02:49 Goffredo Marocchi <panajev at gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >> On Jul 30, 2017, at 11:43 PM, Daryle Walker <darylew at mac.com> wrote:
>> >> The parameters for a fixed-size array type determine the type's
>> size/stride, so how could the bounds not be needed during compile-time? The
>> compiler can't layout objects otherwise.
>> >
>> > Swift is not C; it is perfectly capable of laying out objects at run
>> time.  It already has to do that for generic types and types with resilient
>> members.  That does, of course, have performance consequences, and those
>> performance consequences might be unacceptable to you; but the fact that we
>> can handle it means that we don't ultimately require a semantic concept of
>> a constant expression, except inasmuch as we want to allow users to
>> explicitly request guarantees about static layout.
>>
>> Doesn't this defeat the purpose of generic value parameters? We might as
>> well use a regular parameter if there's no compile-time evaluation
>> involved. In that case, fixed-sized arrays will be useless, because they'll
>> be normal arrays with resizing disabled.
>
>
> OTOH, if the compiler can prove that a local array is never resized, why
> *shouldn't* it get all the benefits of a fixed-sized array without having
> to use a special syntax? Put another way, why shouldn't fixed-size be one
> of those optional attributes for arrays, like ownership will be for
> variables, that users can opt into for more performance but is otherwise
> automatically worked out by the compiler?
>
>
> Because in some cases humans may make an easier judgement call than the
> compiler?
>

Hence, why I'm asking why it shouldn't be an option for the human to help
the compiler with an annotation.

Because the compiler complexity is already growing and compile time is not
> exactly showing massive reductions and people are worried that as Swift
> gains more features and complexity with genetics and reflection and other
> features that compilation time will grow even more?
>

Do you have any evidence that this would be a performance-limiting task for
the compiler? Even if so, what's wrong with limiting the compiler to
inferring only the easiest cases, and allowing for manual annotation to
help the compiler in more complicated ones as an optional performance
enhancement? In other words, my question is, what is wrong with fixed-sized
arrays being--syntactically--simply arrays with resizing disabled? The flip
side of the coin is, why shouldn't normal arrays simply
be--syntactically--fixed-sized arrays with resizing enabled?

As far as I know, the pinnacle of uses for fixed-size arrays is having a
>> compile-time pre-allocated space of the necessary size (either literally at
>> compile-time if that's a static variable, or added to the pre-computed
>> offset of the stack pointer in case of a local variable).
>>
>> > Value equality would still affect the type-checker, but I think we
>> could pretty easily just say that all bound expressions are assumed to
>> potentially resolve unequally unless they are literals or references to the
>> same 'let' constant.
>>
>> Shouldn't the type-checker use the Equatable protocol conformance to test
>> for equality? Moreover, as far as I know, Equatable is not recognized by
>> the compiler in any way, so it's just a regular protocol. What would make
>> it special? Some types would implement operator == to compare themselves to
>> other types, that's beyond the scope of Equatable. What about those? And
>> how are custom operator implementations going to serve this purpose at
>> compile-time? Or will it just ignore the semantics of the type and reduce
>> it to a sequence of bits? Or maybe only a few hand-picked types will be
>> supported?
>>
>> The seemingly simple generic value parameter concept gets vastly
>> complicated and/or poorly designed without an elaborate compile-time
>> execution system... Unless I'm missing an obvious way out.
>>
>> > The only hard constraint is that types need to be consistent, but that
>> just means that we need to have a model in which bound expressions are
>> evaluated exactly once at runtime (and of course typically folded at
>> compile time).
>>
>> What exactly would it take to be able to execute select piece of code at
>> compile-time? Taking the AST, converting it to LLVM IR and feeding it to
>> the MCJIT engine seems to be easy enough. But I'm pretty sure it's more
>> tricky than that. Is there a special assumption or two made about the code
>> that prevents this from happening?
>>
>> > John.
>> >
>> >> Or do you mean that the bounds are integer literals? (That's what I
>> have in the design document now.)
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 30, 2017, at 8:51 PM, John McCall <rjmccall at apple.com> wrote:
>> >>
>> >>>> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>>> The “constexpr” facility from C++ allows users to define constants
>> and functions that are determined and usable at compile-time, for
>> compile-time constructs but still usable at run-time. The facility is a key
>> step for value-based generic parameters (and fixed-size arrays if you don’t
>> want to be stuck with integer literals for bounds). Can figuring out
>> Swift’s story here be part of Swift 5?
>> >>>
>> >>> Note that there's no particular reason that value-based generic
>> parameters, including fixed-size arrays, actually need to be constant
>> expressions in Swift.
>> >>>
>> >>> John.
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/44dba8e4/attachment.html>