Add generic associatedtypes and generalized supertype constraints #13012

anandabits · 2017-11-18T17:26:59Z

This PR adds a few items to the generics manifesto. The first two were discussed briefly on Twitter where @DougGregor requested a PR to add them. I plan to followup with a pitch to Swift evolution for generalized supertype constraints after this is merged.

slavapestov · 2017-11-18T17:38:55Z

docs/GenericsManifesto.md

@@ -87,6 +87,21 @@ typealias StringDictionary<Value> = Dictionary<String, Value>
 var d1 = StringDictionary<Int>()
 var d2: Dictionary<String, Int> = d1 // okay: d1 and d2 have the same type, Dictionary<String, Int>
 ```
+### Generic associatedtypes


"associated types" here and below

That’s how I would usually write it but I followed the precedent of “typealiases” that’s already in this document.

I think that should be fixed too. In diagnostics we tend to say "type alias" not "typealias"

Do you suggest I include fixes for all of them in this PR?

@DougGregor any thoughts on this? Should I make the change from "associatedtypes" to "associated types" and "typealiases" to "type aliases" in this PR?

It's probably worth a small note about how this might look from the perspective of somebody trying to conform to a protocol with generic associated types. The way I guess it would work is that a generic associated-type would require a generic type alias in the conforming type. So the generic type which fulfils that requirement may have more generic parameters, as long as they are all bound to parameters in the parent type or to concrete types.

So in your example, Wrapped<T> could be a tuple of (Int, T), or an Array<T>, or a Dictionary<SomeNestedGenericParameter, T>. Is that correct?

@karwa This is a good idea. I'll be updating the PR with a note about this shortly. Your understanding is correct.

xwu · 2017-11-18T18:06:52Z

docs/GenericsManifesto.md

@@ -592,6 +622,43 @@ one cannot directly specify `T`: either one calls `f` (and `T` is determined via
 ```Swift
 let x = f<Int> // x has type (Int) -> Void
 ```
+### Conditional default arguments


Drive-by nit: please add an empty line above this (and also, above the heading "Generic associated types").

slavapestov · 2017-11-19T02:07:25Z

docs/GenericsManifesto.md

@@ -592,6 +622,43 @@ one cannot directly specify `T`: either one calls `f` (and `T` is determined via
 ```Swift
 let x = f<Int> // x has type (Int) -> Void
 ```
+### Conditional default arguments


Has this feature been discussed previously anywhere? I don't think we should add it to the document. The other two are "canonical" generics features that we have all talked about before.

Not to my knowledge. It was on my mind while I was writing this so I added it. I can remove it if others agree that it shouldn’t be added.

I guess I'd rather have it removed from this PR and discuss it on swift-evolution a little bit first to get some basic syntax ideas in place. And I do want to discuss this... it's something that we might be able to use to help simplify associated type inference.

Sounds good. I'll remove it when I update the PR and send a separate pitch on evolution.

I was thinking of this primarily as a way to reduce the pain of providing an interface like this but if it can help simplify associated type inference it would move up the priority list for me quite a bit. I have been seeing associated type inference issues in code that uses an overload set like this.

DougGregor · 2017-11-20T22:03:41Z

docs/GenericsManifesto.md

+}
+```
+
+In the above example `Base` may be any non-final class or existential type.  If `Base` is a class `Derived` must inherit from `Base`.  If `Base` is an existential `Derived` may be any type that provides a compatible conformance, including a value type.


I had assumed that we were talking about a superclass constraint here, but I think it generalizes to existentials correctly. It's slightly bothersome to have the requirement on Base be "non-final class or existential type", and I wonder if perhaps there's a looser definition that's okay. For example, maybe Base == Derived is always okay, even if Base is (say) a value type.

That's good feedback. I didn't word this precisely enough.

I think it makes sense to allow Base to be any type. Derived may be the same as Base, a subclass of Base when Base is a non-final class or a conforming type when Base is an existential. I definitely have use cases for existentials and I can imagine occasional problems if Base == Derived was not allowed.

If it's not too difficult for an initial implementation, I would like to see this work with all subtype relationships including T: T? and ((Base) -> Void): ((Derived) -> Void) (as well as any other subtype relationships added in the future). This is really how I think of fully generalized supertype constraints.

Does that loosening make sense?

Yes, that makes sense to me.

Would it be clearer to refer to these as "is" constraints? Derived may be any type so long as values of that type return true from a is Base condition.

DougGregor · 2017-11-20T22:05:01Z

docs/GenericsManifesto.md

@@ -592,6 +622,43 @@ one cannot directly specify `T`: either one calls `f` (and `T` is determined via
 ```Swift
 let x = f<Int> // x has type (Int) -> Void
 ```
+### Conditional default arguments


I guess I'd rather have it removed from this PR and discuss it on swift-evolution a little bit first to get some basic syntax ideas in place. And I do want to discuss this... it's something that we might be able to use to help simplify associated type inference.

anandabits · 2017-11-24T22:45:54Z

@DougGregor I have removed the discussion of conditional default arguments and updated the discussion of generalized supertype constraints.

DevAndArtist · 2018-06-19T15:03:48Z

This really should be merged 👍

CodaFi · 2019-11-17T23:30:33Z

@DougGregor Is this still a direction we want to go in?

DevAndArtist · 2019-11-18T07:40:22Z

I personally would wish that at least generalized super type constraint would eventually become a thing in Swift. I bumped too many times where I couldn‘t tell the compiler some natural context related sub-type relation, which requires a runtime workaround instead of a compile-time type-safety.

CodaFi · 2019-11-18T23:07:55Z

Got the green light from Doug

⛵️

@swift-ci please smoke test and merge

slavapestov reviewed Nov 18, 2017

View reviewed changes

xwu reviewed Nov 18, 2017

View reviewed changes

slavapestov reviewed Nov 19, 2017

View reviewed changes

DougGregor reviewed Nov 20, 2017

View reviewed changes

anandabits force-pushed the generics-manifesto branch from 163c6ab to 08bf0b4 Compare November 24, 2017 22:44

anandabits changed the title ~~Add generic associatedtypes, generalized supertype constraints and conditional default arguments~~ Add generic associatedtypes and generalized supertype constraints Nov 24, 2017

Add generic associatedtypes and generalized supertype constraints

2cff06d

anandabits force-pushed the generics-manifesto branch from 08bf0b4 to 2cff06d Compare November 24, 2017 23:27

CodaFi assigned DougGregor Nov 18, 2019

swift-ci merged commit f507e7b into swiftlang:master Nov 19, 2019

Add generic associatedtypes and generalized supertype constraints #13012

Add generic associatedtypes and generalized supertype constraints #13012

Uh oh!

Conversation

anandabits commented Nov 18, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xwu Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anandabits Nov 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anandabits commented Nov 24, 2017

Uh oh!

DevAndArtist commented Jun 19, 2018

Uh oh!

CodaFi commented Nov 17, 2019

Uh oh!

DevAndArtist commented Nov 18, 2019

Uh oh!

CodaFi commented Nov 18, 2019

Uh oh!

Uh oh!

xwu Nov 18, 2017 •

edited

Loading

anandabits Nov 20, 2017 •

edited

Loading