Just a quick thought, but isn't this what NSArray is for? If you know the type
of a thing at runtime, it's probably best to use the part of the language that
will help you most in that area: the Objective-C bridge.
Doug is right that this is the shade of dependent types and would require a
computation rule in the type system. For example, what type does Array have
here:
// In some far-off module
func DefeatOptimizer() -> Bool { return false }
// Back home again
var ty = Any.Type
for i in (0..<INT_MAX) {
sleep(i)
if DefeatOptimizer() { return; }
if (i % 2 == 0) {
ty = Int.self
}
if (i % 2 == 1) {
ty = String.self
}
}
var arr = Array<ty>()
To which you might say "clearly it's Array<ty> like you said!" but the type
system still maintains a phase distinction between types and values so we'll
have to compute it and that would be a little ridiculous, right? If you wanted
to clean this up, you might require something like the C++ constexpr
restriction on the computation rule, but I can counter by recursing. OK, so
remove recursion. What about a large stack of (potentially unoptimizable)
branches? Remove branching. Now we're left with, well, your example and we're
back to square one.
~Robert Widmann
2016/04/20 11:36、Joanna Carter via swift-evolution <[email protected]>
のメッセージ:
> Hi Doug
>
>> In programming-language circles, this feature is called “dependent types”
>> (see, e.g., https://en.wikipedia.org/wiki/Dependent_type), and it introduces
>> significant complicates into a type system. For example, determining whether
>> two types are equivalent becomes a run-time property rather than a
>> compile-time property. I don’t know if Swift will end with a
>> dependently-typed type system. To get there, we would need a number of very
>> strongly-motivating use cases illustrating how common programming tasks can
>> be improved with dependent types, and we would need to solid plan for
>> managing the complexity―both implementation complexity in the compiler’s
>> type checker and also the language complexity seen by Swift user’s when they
>> encounter this feature.
>
> I must admit to being ever so slightly confused about your connection with
> "dependent types"; in all my years of programming, I have never come across
> the context of the expression as found in the article cited. Anything that
> needs algebraic formulae to explain is far too complicated for mere mortal
> programmers and I am willing to state that I certainly didn't understand more
> than a few words.
>
> All I am postulating is the ability to create instances of generic types,
> bound to (a) parameter type(s) in the same manner as is currently possible
> with non-generic types.
>
> To bring it down to basics, take the example of wanting to create an array of
> a given type of objects:
>
> let aType: Any.Type = Int.self
>
> var arr = [aType]
>
> … creates an array of Any.type…
>
> let aType: Any.Type = Int.self
>
> var arr = [aType]()
>
> … results in an error "Invalid use of '()' to call a value of non-function
> type '[Any.Type]'"
>
> let aType: Any.Type = Int.self
>
> var arr = Array<aType>()
>
> … results in an error "'aType' is not a type"
>
>
> So, how are we meant to be able to create arrays, or any other generic type
> that require to be bound to a type known only at runtime?
>
> In C#, We have the Type class, which contains useful properties like
> isGenericType, isConstructedGenericType and methods like
> GetGenericArguments() and, most important to this use case,
> MakeGenericType(Type []).
>
> I would make a strong argument for completing Swift generics by including
> such facilities in Any.Type, so that:
>
> 1. we do not have to use the somewhat cumbersome Mirror mechanism
>
> 2. we can do something useful with instances of Any.Type, which, at present,
> does absolutely nothing.
>
> Adding similar functionality to C#'s Type class to Any.Type would break
> absolutely zero code but would make life a whole load easier for those of us
> who are power users of generics. Otherwise, FMPOV, Swift generics are but a
> pale imitation of the concept and very much second class citizens in the
> language.
>
> Joanna
>
> --
> Joanna Carter
> Carter Consulting
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
