[proposal] Generic type aliases


(Chris Lattner) #1

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

    typealias StringDictionary<T> = Dictionary<String, T>
    typealias IntFunction<T> = (T) -> Int
    typealias MatchingTriple<T> = (T, T, T)
    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.


(Daniel Duan) #2

Chris Lattner via swift-evolution <swift-evolution@...> writes:

Hi All,

I’ve started prototyping generic type aliases in master

+1. This would be a very useful feature. To add a data point, apparently
I wanted this more than a year ago :slight_smile:

https://twitter.com/daniel_duan/status/552889831202635776


(Howard Lovatt) #3

+1. It would be handy for:

typealias Vec3<T> = (T, T, T)
typealias Mat3x3<T> = (Vec3<T>, Vec3<T>, Vec3<T>)

  -- Howard.

···

On 10 March 2016 at 15:47, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to
run this through the evolution process for discussion. Comments and
discussion are welcome. Here’s the start of the email thread for the
actual formal proposal:

*Introduction*

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

*Motivation*

Generic typealiases are a somewhat obvious generalization of the existing
Swift model for type aliases, which allow you to provide a name for an
existing nominal generic type, or to provide a name for a non-nominal type
(e.g. tuples, functions, etc) with generic parameters.

*Proposed solution*

The solution solution is straight-forward: allow type aliases to introduce
type parameters, which are in scope for their definition. This allows one
to express things like:

    typealias StringDictionary<T> = Dictionary<String, T>
    typealias IntFunction<T> = (T) -> Int
    typealias MatchingTriple<T> = (T, T, T)
    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

This is consistent with the rest of Swift’s approach to generics, and
slots directly into the model.

*Detailed design*

This is a minimal proposal for introducing type aliases into Swift, and
intentionally chooses to keep them limited to being “aliases”. As such,
additional constraints are not allowed in this base proposal, e.g. you
can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String,
>

Otherwise, generic type aliases follow the model of type aliases and the
precedent of the other generic declarations in Swift. For example, they
allow the usual access control features that type aliases support.
Similarly, like non-generic type aliases, generic type aliases cannot be
“resilient”.

*Impact on existing code*

This is a new feature, so there is no impact on existing code.

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


(Thorsten Seitz) #4

+1
This is very welcome!

-Thorsten

···

Am 10.03.2016 um 05:47 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

    typealias StringDictionary<T> = Dictionary<String, T>
    typealias IntFunction<T> = (T) -> Int
    typealias MatchingTriple<T> = (T, T, T)
    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.

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


(Russ Bishop) #5

What is the rationale for not supporting constraints? Generic type aliases have value without constraints but I can also see a lot of uses for allowing them, especially in some cases where the type constraints are fairly complex and repetitive. It also serves the same self-documenting-code purposes.

In this example it would be nonsense to have a “MatcherFunction” that can’t compare values. Why not express that in the constraint?

    typealias MatcherFunction<T where T : Comparable> = (T, T) -> MatchResult

Russ

···

On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>


(Joe Groff) #6

Can we at least infer existing constraints from the aliased type? For example, in something like:

typealias FakeSet<T> = Dictionary<T, ()>

you'd need to propagate the `T: Hashable` constraint from `Dictionary`'s first parameter to the typealias for it to be sound.

-Joe

···

On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.


(E. Maloney) #7

I would love to have this feature.

I've tried to do this before in Swift, assuming it was supported. I'm sure I'm not the only one.

···

On Mar 9, 2016, at 11:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

    typealias StringDictionary<T> = Dictionary<String, T>
    typealias IntFunction<T> = (T) -> Int
    typealias MatchingTriple<T> = (T, T, T)
    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.

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


(Adrian Zubarev) #8

Will this feature allow something like this?

protocol SomeProtocol: class { /* some functions here */ }
typealias ProtoView<T: UIView where T: SomeProtocol> = T

I recently came across a design issue where I needed this type to be global instead of the generic top level of a class:

class A<T: UIView where T: SomeProtocol> { /*...*/ }

I couldn’t do something like this in my project and was forced to extend UIView with some kind of an extra backdoor protocol.

···

--
Adrian Zubarev
Sent with Airmail

Am 10. März 2016 bei 05:47:50, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb:

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

typealias StringDictionary&lt;T&gt; = Dictionary&lt;String, T&gt;
typealias IntFunction&lt;T&gt; = \(T\) \-&gt; Int
typealias MatchingTriple&lt;T&gt; = \(T, T, T\)
typealias BackwardTriple&lt;T1,T2,T3&gt; = \(T3, T2, T1\)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

typealias StringDictionary&lt;T where T : Hashable&gt; = Dictionary&lt;String, T&gt;

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.

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


(Pierre Monod-Broca) #9

+1 It looks good to me.

Probably a first step toward something more.

Pierre

···

Le 10 mars 2016 à 05:54, Howard Lovatt via swift-evolution <swift-evolution@swift.org> a écrit :

+1. It would be handy for:

typealias Vec3<T> = (T, T, T)
typealias Mat3x3<T> = (Vec3<T>, Vec3<T>, Vec3<T>)

  -- Howard.

On 10 March 2016 at 15:47, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

    typealias StringDictionary<T> = Dictionary<String, T>
    typealias IntFunction<T> = (T) -> Int
    typealias MatchingTriple<T> = (T, T, T)
    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.

_______________________________________________
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


(Chris Lattner) #10

Since writing the proposal up (and since discussing it with you), I have come around to disagree with the proposal as I wrote it. Specifically, I think that constraints of the aliasee *should* be specified in the typealias declaration. You should be required to write:

  typealias DictionaryOfString<T : Hashable> = Dictionary<T, String>

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

First, we want the source code for the decl to be obvious and self describing.

Second, this simplifies the type checker, by eliminating the need for it to do global analysis.

-Chris

···

On Mar 16, 2016, at 12:39 PM, Joe Groff <jgroff@apple.com> wrote:

On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Can we at least infer existing constraints from the aliased type? For example, in something like:

typealias FakeSet<T> = Dictionary<T, ()>

you'd need to propagate the `T: Hashable` constraint from `Dictionary`'s first parameter to the typealias for it to be sound.


(Chris Lattner) #11

I totally see the value in extending the model to support this. My rationale for excluding it from the initial proposal is to start with something that is “obvious” to get the feature in, then allow the more controversial pieces to be discussed as independent extensions, which can be motivated by specific use cases as necessary.

-Chris

···

On Mar 16, 2016, at 12:23 PM, Russ Bishop <xenadu@gmail.com> wrote:

On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

What is the rationale for not supporting constraints? Generic type aliases have value without constraints but I can also see a lot of uses for allowing them, especially in some cases where the type constraints are fairly complex and repetitive. It also serves the same self-documenting-code purposes.

In this example it would be nonsense to have a “MatcherFunction” that can’t compare values. Why not express that in the constraint?

    typealias MatcherFunction<T where T : Comparable> = (T, T) -> MatchResult


(Adrian Zubarev) #12

Ok I read all the previous posts and I’m totally fine with this feature as it’s mentioned in its base form. Looking forward to see generic typealias allowing type constraints.

There is one thing still on my mind: how do we use a generic typealias?

typealias SomeTuple<T> = (T, T)

func foo<U>(tuple: SomeTuple<U>) { /*…*/ }

or only for Ints

func foo(tuple: SomeTuple<Int>) { /*…*/ }

What about global generic typealias?

class Boo<T> {

  var tuple: SomeTuple<T>

  init(tuple: SomeTuple<T>) {

    self.tuple = tuple // what is T here?
  }
}

Lets say generic typealias already has the possibility to specify type constraints at this point.
Here is a quick minimal sample code where I would want to use a global generic typealias and keep the class as non-generic:


protocol ChildProtocol: class {
	func foo()
}

protocol Delegate: class {
	// easy to use because MyClass is non-generic
	func parentDidSomething(class: ParentClass)
}

// for any type 
// typealias ViewWithProtocol<T: ChildProtocol> = T

// or better allowing only UIView as base class + ChildProtocol
typealias ViewWithProtocol<T: UIView where T: ChildProtocol> = T

class ParentClass {

	var delegate: MyDelegate?

	var child: ViewWithProtocol<UIView> // any UIView that extends with ChildProtocol can be stored here
		
	init(child: ViewWithProtocol<UIView>) {
			
		self.child = child
		self.doSomeWork()
	}

	// it’s easy to access the property
	func doSomeWork() {
			
		self.child.foo()
		self.child.tag = 42 // since it’s a UIView which has the `tag` property
	}
}

One additional cool feature of generic typealias would be the possibility to access default implementation functions which are not specified inside the protocol body itself:


protocol SomeProtocol {}

extension SomeProtocol where Self: BaseClass {
		
	func print(text: String) {
		print(text)
	}
}

class BaseClass {}
class SubClass: BaseClass {
		
	var text = "hello world"
}

typealias BaseClassWithProtocol<T: BaseClass where T: SomeProtocol> = T

func printSomethingWith(instance: BaseClassWithProtocol<SubClass>) {

	instance.print(instance.text) // should print "hello world"
}

+1 for this feature

···

--
Adrian Zubarev
Sent with Airmail

Am 21. März 2016 bei 11:16:06, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Will this feature allow something like this?

protocol SomeProtocol: class { /* some functions here */ }
typealias ProtoView<T: UIView where T: SomeProtocol> = T

I recently came across a design issue where I needed this type to be global instead of the generic top level of a class:

class A<T: UIView where T: SomeProtocol> { /*...*/ }

I couldn’t do something like this in my project and was forced to extend UIView with some kind of an extra backdoor protocol.
--
Adrian Zubarev
Sent with Airmail

Am 10. März 2016 bei 05:47:50, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb:

Hi All,

I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:

Introduction

This proposal aims to add generic typealiases to Swift.

Swift-evolution thread: <you are here>

Motivation

Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.

Proposed solution

The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:

typealias StringDictionary&lt;T&gt; = Dictionary&lt;String, T&gt;
typealias IntFunction&lt;T&gt; = \(T\) \-&gt; Int
typealias MatchingTriple&lt;T&gt; = \(T, T, T\)
typealias BackwardTriple&lt;T1,T2,T3&gt; = \(T3, T2, T1\)

This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.

Detailed design

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

typealias StringDictionary&lt;T where T : Hashable&gt; = Dictionary&lt;String, T&gt;

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Impact on existing code

This is a new feature, so there is no impact on existing code.

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


(Joe Groff) #13

This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:

    typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>

Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. For example, they allow the usual access control features that type aliases support. Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.

Can we at least infer existing constraints from the aliased type? For example, in something like:

typealias FakeSet<T> = Dictionary<T, ()>

you'd need to propagate the `T: Hashable` constraint from `Dictionary`'s first parameter to the typealias for it to be sound.

Since writing the proposal up (and since discussing it with you), I have come around to disagree with the proposal as I wrote it. Specifically, I think that constraints of the aliasee *should* be specified in the typealias declaration. You should be required to write:

  typealias DictionaryOfString<T : Hashable> = Dictionary<T, String>

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global analysis, just an analysis of the RHS of the typealias.

-Joe

···

On Mar 16, 2016, at 4:42 PM, Chris Lattner <clattner@apple.com> wrote:

On Mar 16, 2016, at 12:39 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

First, we want the source code for the decl to be obvious and self describing.

Second, this simplifies the type checker, by eliminating the need for it to do global analysis.

-Chris


(Chris Lattner) #14

I consider the RHS of the typealias to be the “body” of the type alias, and parameters to be part of the “signature” of the funcdecl.

-Chris

···

On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff@apple.com> wrote:

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global analysis, just an analysis of the RHS of the typealias.


(Brent Royal-Gordon) #15

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global analysis, just an analysis of the RHS of the typealias.

I consider the RHS of the typealias to be the “body” of the type alias, and parameters to be part of the “signature” of the funcdecl.

The RHS of a stored variable declaration is essentially its body, but we infer types across that boundary. (Granted, not generic constraints since variables can't be generic yet.)

···

--
Brent Royal-Gordon
Architechies


(Joe Groff) #16

I'm OK starting with the base design that constraints have to be explicit. My gut tells me though that `typealias` is close enough syntactically to `var` that many people will expect the inference to occur, but we can always add it later.

-Joe

···

On Mar 16, 2016, at 5:02 PM, Chris Lattner <clattner@apple.com> wrote:

On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global analysis, just an analysis of the RHS of the typealias.

I consider the RHS of the typealias to be the “body” of the type alias, and parameters to be part of the “signature” of the funcdecl.


(Andrew Bennett) #17

Big +1 on this proposal from me.

Does this proposal allow a protocol can have generic associated types?

   - associatedtype Something<T>
   - associatedtype Something<T: Hashable>

It's not mentioned, but I think it would be necessary at some point for
completeness.

···

On Thu, Mar 17, 2016 at 2:32 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

On Mar 16, 2016, at 5:02 PM, Chris Lattner <clattner@apple.com> wrote:

On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff@apple.com> wrote:

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer
hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global
analysis, just an analysis of the RHS of the typealias.

I consider the RHS of the typealias to be the “body” of the type alias,
and parameters to be part of the “signature” of the funcdecl.

I'm OK starting with the base design that constraints have to be explicit.
My gut tells me though that `typealias` is close enough syntactically to
`var` that many people will expect the inference to occur, but we can
always add it later.

-Joe

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


(Dave Abrahams) #18

I have the same concern as Joe does, but am willing to wait until people
complain :slight_smile:

···

on Wed Mar 16 2016, Joe Groff <swift-evolution@swift.org> wrote:

On Mar 16, 2016, at 5:02 PM, Chris Lattner <clattner@apple.com> wrote:

On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

We shouldn’t infer it the requirement.

Rationale: I see this as analogous (in two ways) to why we don’t infer hashability of T in:

func f<T>(…) {
  let x : Dictionary<T, String>
}

However, we do infer the `T: Hashable` in a case like this:

func foo<T>(x: Dictionary<T, String>) {}

`typealias` feels similar to that to me. It doesn't have to be a global analysis, just an analysis of the RHS of the typealias.

I consider the RHS of the typealias to be the “body” of the type alias, and parameters to be part of the “signature” of the funcdecl.

I'm OK starting with the base design that constraints have to be
explicit. My gut tells me though that `typealias` is close enough
syntactically to `var` that many people will expect the inference to
occur, but we can always add it later.

--
Dave


(Joe Groff) #19

This would fall under the "higher-kinded types" umbrella.

-Joe

···

On Mar 16, 2016, at 11:20 PM, Andrew Bennett <cacoyi@gmail.com> wrote:

Big +1 on this proposal from me.

Does this proposal allow a protocol can have generic associated types?
associatedtype Something<T>
associatedtype Something<T: Hashable>
It's not mentioned, but I think it would be necessary at some point for completeness.