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.
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? 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
