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:
```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: 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:
```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: 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 ([email protected])
schrieb:
Will this feature allow something like this?
```swift
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:
```swift
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
([email protected]) 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<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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
