Sent from my iPhone
> On Apr 20, 2016, at 8:36 AM, Joanna Carter <[email protected]> > wrote: > > 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. Programming language theory (PL) tends to be painfully formal; much of what Swift's type system can be describe in PL formalisms as well. My point is that your suggestion falls into a known theoretical framework that adds significant complications to the type system (and compiler pipeline in general). That complexity needs to be understood and managed. > > 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. Yes. It's bringing runtime type information into the static type system. > > 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? [Any] is a heterogenous array of elements whose types are 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 []). This is a reflection facility. Swift should get better reflection, but that's a very different thing from dependent types. > > 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 It's a stretch to call reflection part of the generics system, but it is a feature were interested in improving upon in the future. - Doug _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
