Re: [swift-evolution] [proposal] Generic type aliases

[Adrian Zubarev via swift-evolution]

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)

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

or only for Ints

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

What about global generic typealias?

class Boo {

var tuple: SomeTuple

init(tuple: SomeTuple) {

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:

```swift

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

// or better allowing only UIView as base class + ChildProtocol
typealias ViewWithProtocol = T

class ParentClass {

var delegate: MyDelegate?

var child: ViewWithProtocol // any UIView that extends with 
ChildProtocol can be stored here

init(child: ViewWithProtocol) {

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:

```swift

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

func printSomethingWith(instance: BaseClassWithProtocol) {

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.zuba...@devandartist.com) 
schrieb:

Will this feature allow something like this?

```swift
protocol SomeProtocol: class { /* some functions here */ }
typealias ProtoView = 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:
```swift
class A { /*...*/ }
```

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: 

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 = Dictionary
    typealias IntFunction = (T) -> Int
    typealias MatchingTriple = (T, T, T)
    typealias BackwardTriple = (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 = Dictionary

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

Re: [swift-evolution] [proposal] Generic type aliases

[Andrew Bennett via swift-evolution]

Big +1 on this proposal from me.

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

   - associatedtype Something
   - associatedtype Something

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  wrote:
>
> On Mar 16, 2016, at 4:56 PM, Joe Groff  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(…) {
>   let x : Dictionary
> }
>
>
> However, we do infer the `T: Hashable` in a case like this:
>
> func foo(x: Dictionary) {}
>
> `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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [proposal] Generic type aliases

[Joe Groff via swift-evolution]

> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution 
>  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 = Dictionary
> 
> 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 = Dictionary

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

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

Re: [swift-evolution] [proposal] Generic type aliases

[Chris Lattner via swift-evolution]

On Mar 16, 2016, at 4:56 PM, Joe Groff  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(…) {
>>   let x : Dictionary
>> }
> 
> However, we do infer the `T: Hashable` in a case like this:
> 
> func foo(x: Dictionary) {}
> 
> `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.

-Chris

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

Re: [swift-evolution] [proposal] Generic type aliases

[Russ Bishop via swift-evolution]

> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution 
>  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 = Dictionary
> 

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, T) -> MatchResult




Russ

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

Re: [swift-evolution] [proposal] Generic type aliases

[Chris Lattner via swift-evolution]

> On Mar 16, 2016, at 12:23 PM, Russ Bishop  wrote:
> 
> 
>> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution 
>> > 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 = Dictionary
>> 
> 
> 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, T) -> MatchResult

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

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

Re: [swift-evolution] [proposal] Generic type aliases

[Brent Royal-Gordon via swift-evolution]

>> However, we do infer the `T: Hashable` in a case like this:
>> 
>> func foo(x: Dictionary) {}
>> 
>> `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

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

Re: [swift-evolution] [proposal] Generic type aliases

[Joe Groff via swift-evolution]

> On Mar 16, 2016, at 5:02 PM, Chris Lattner  wrote:
> 
> On Mar 16, 2016, at 4:56 PM, Joe Groff  > 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(…) {
>>>   let x : Dictionary
>>> }
>> 
>> However, we do infer the `T: Hashable` in a case like this:
>> 
>> func foo(x: Dictionary) {}
>> 
>> `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