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

[Dave Abrahams via swift-evolution]

on Wed Apr 20 2016, Joanna Carter  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.

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

-- 
Dave

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

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

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Apr 20, 2016, at 8:36 AM, Joanna Carter  
> 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() 
> 
> … 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Developer via swift-evolution]

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

> 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() 
> 
> … 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

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() 

… 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

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

[Joanna Carter via swift-evolution]

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