[swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

[Developer]

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 <swift-evolution at swift.org> のメッセージ:

> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution