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

[John McCall]

> On Jul 31, 2017, at 11:29 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> No, this is a misunderstanding: I mean "you" as yourself, not "you" as the compiler. As far as I know, given a type variable, as in `let foo: NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to instantiate a generic type.

Ah, yes, I did misunderstand what you were saying.

> The question stands again: are there any specific reasons that you can't do that right now, or is it just because the need for this is not particularly evident?

There is no specific reason you can't do that right now.  We could certainly just allow you to name a local constant in type contexts if it happens to be of metatype type — I don't know if that would be the best language design, but there's nothing inherent about the language model that makes it unreasonable.  I do think we would at least demand that it be a constant and not a variable.

John.


> 
> Félix
> 
>> Le 31 juil. 2017 à 11:29, John McCall <rjmccall at apple.com> a écrit :
>> 
>>> On Jul 31, 2017, at 3:58 AM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>>> It seems to me that this applies just the same to type generic parameters. Are there any reason that you can't instantiate a generic type at runtime, or is it just because the need is not as evident as it would/could be with non-type generic parameters?
>> 
>> Are you under the impression that Swift does not, today, instantiate generic types at runtime?
>> 
>> A lot of this entire thread seems to be premised on really weird, incorrect assumptions about the Swift compilation model.
>> 
>> John.
>> 
>>> 
>>>> Le 30 juil. 2017 à 21:10, John McCall via swift-evolution <swift-evolution at swift.org> a écrit :
>>>> 
>>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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).
>>>> 
>>>> 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
>>> 
>> 
>