> On Jul 31, 2017, at 11:29 PM, Félix Cloutier <felix...@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 <rjmcc...@apple.com> a écrit : >> >>> On Jul 31, 2017, at 3:58 AM, Félix Cloutier <felix...@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@swift.org> a écrit : >>>> >>>>> On Jul 30, 2017, at 11:43 PM, Daryle Walker <dary...@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 <rjmcc...@apple.com> wrote: >>>>> >>>>>>> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution >>>>>>> <swift-evolution@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@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
