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


(Joanna Carter) #1

I often find myself needing to construct an instance of a bound generic type at runtime, in much the same manner as I would a "standard" type.

e.g.

As for a standard type…

let aType = Int.Type

let anInt = aType.init(0)

I also want to be able to use the same mechanism for a generic type…

struct MyStruct<T: Equatable /*, etc */>
{
  var value: T?
}

let paramType = // type from streaming or reflection compliant with Equatable

let structType = MyStruct<paramType>.self

let f = structType.init()

At present, the following compiler error is raised…

'paramType' is not a type

I am the only one to require this behaviour? If not, do we want a proposal? If so, could you let me know your views on its worthiness?

Joanna

···

--
Joanna Carter
Carter Consulting


(Howard Lovatt) #2

I would also find this useful, should this be part of completing generics?

···

On Monday, 18 April 2016, Joanna Carter via swift-evolution < swift-evolution@swift.org> wrote:

I often find myself needing to construct an instance of a bound generic
type at runtime, in much the same manner as I would a "standard" type.

e.g.

As for a standard type…

let aType = Int.Type

let anInt = aType.init(0)

I also want to be able to use the same mechanism for a generic type…

struct MyStruct<T: Equatable /*, etc */>
{
  var value: T?
}

let paramType = // type from streaming or reflection compliant with
Equatable

let structType = MyStruct<paramType>.self

let f = structType.init()

At present, the following compiler error is raised…

'paramType' is not a type

I am the only one to require this behaviour? If not, do we want a
proposal? If so, could you let me know your views on its worthiness?

Joanna

--
Joanna Carter
Carter Consulting

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Douglas Gregor) #3

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.

  - Doug

···

On Apr 17, 2016, at 7:13 AM, Joanna Carter via swift-evolution <swift-evolution@swift.org> wrote:

I often find myself needing to construct an instance of a bound generic type at runtime, in much the same manner as I would a "standard" type.

e.g.

As for a standard type…

let aType = Int.Type

let anInt = aType.init(0)

I also want to be able to use the same mechanism for a generic type…

struct MyStruct<T: Equatable /*, etc */>
{
var value: T?
}

let paramType = // type from streaming or reflection compliant with Equatable

let structType = MyStruct<paramType>.self

let f = structType.init()

At present, the following compiler error is raised…

'paramType' is not a type

I am the only one to require this behaviour? If not, do we want a proposal? If so, could you let me know your views on its worthiness?


(Patrick Smith) #4

If I needed functionality like this, I would create an enum with a case and associated value for every type I needed.
enum AnyValue : Equatable { case int(Int) case string(String) // etc}

Patrick

···

On Sun, Apr 17, 2016 at 7:13 AM -0700, "Joanna Carter via swift-evolution" <swift-evolution@swift.org> wrote:

I often find myself needing to construct an instance of a bound generic type at runtime, in much the same manner as I would a "standard" type.

e.g.

As for a standard type…

let aType = Int.Type

let anInt = aType.init(0)

I also want to be able to use the same mechanism for a generic type…

struct MyStruct
{
  var value: T?
}

let paramType = // type from streaming or reflection compliant with Equatable

let structType = MyStruct.self

let f = structType.init()

At present, the following compiler error is raised…

'paramType' is not a type

I am the only one to require this behaviour? If not, do we want a proposal? If so, could you let me know your views on its worthiness?

Joanna

--
Joanna Carter
Carter Consulting

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joanna Carter) #5

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


(Douglas Gregor) #6

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

···

Sent from my iPhone

On Apr 20, 2016, at 8:36 AM, Joanna Carter <joanna@carterconsulting.org.uk> wrote:


(Dave Abrahams) #7

Not commenting on the rest of your post, but you can compare instances
of Any.Type with == and !=.

···

on Wed Apr 20 2016, Joanna Carter <swift-evolution@swift.org> wrote:

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.

--
Dave


(Robert Widmann) #8

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