I am learning swift and playing with Xcode.
and I always dig into the definitions. I have seen that:
public protocol GeneratorType {
typealias Element
#warn_unused_result
public mutating func next() -> Self.Element?
}
A struct that conforming this protocol:
public struct IndexingGenerator<Elements : Indexable> : GeneratorType, SequenceType {
public init(_ elements: Elements)
public mutating func next() -> Elements._Element?
}
I know 'Self' means that returning the conforming type. But what does 'Self.Element' mean?
and the function that implemented the requirement that returning 'Elements._Element?', I can’t see 'Elements._Element?' is equal to 'Self.Element?'.
Can anyone explain to me this?
and tell me more about this. thank you.
Self.Element refers to the concrete type that any type implementing GeneratorType protocol will declare as its Element typealias.
For example, in this generator of Fibonacci numbers:
struct Fibonacci: GeneratorType {
typealias Element = Int
private var value: Int = 1
private var previous: Int = 0
mutating func next() -> Element? {
let newValue = value + previous
previous = value
value = newValue
return previous
}
}
... you implement GeneratorType protocol and indicate what will be its Element typealias (Int in this case), and that's the type that generator's next() will be returning (well, actually the optional of that type).
Quite often, though, you would not have to explicitly specify typealiases when implementing parametrised protocols, as Swift is smart enough to infer them for you. E.g. for the Fibonacci numbers generator from the above example the following will also do:
struct Fibonacci: GeneratorType {
private var value: Int = 1
private var previous: Int = 0
mutating func next() -> Int? {
let newValue = value + previous
previous = value
value = newValue
return previous
}
}
... Swift knows from the signature of next() that it returns Int?, and that GeneratorType implementors also must have next() in their to-do list, and that these methods must return Element? types. So, Swift just puts 2 and 2 together, and infers that Element? must be the same thing as Int?, and therefore Element == Int.
About this:
public struct IndexingGenerator<Elements : Indexable> : GeneratorType, SequenceType {
public init(_ elements: Elements)
public mutating func next() -> Elements._Element?
}
Here we have four things going on:
We declare generic type IndexingGenerator that takes a parameter-type called Elements.
This Elements type has a constraint that it must implement Indexable protocol.
The generator that we implement is supposed to return values of the type that is accessible via Indexable interface of Elements, which is known to IndexingGenerator via dot-syntax as Elements._Element.
Swift infers that Element of IndexingGenerator is the same thing as Elements._Element.
So, essentially the above delclaration is equivalent to:
public struct IndexingGenerator<Elements : Indexable> : GeneratorType, SequenceType {
public typealias Element = Elements._Element
public init(_ elements: Elements)
public mutating func next() -> Element?
}
Finally, if curious why _Element and not just Element like in GeneratorType, here is what they write in the open-source Swift repository (under swift/stdlib/public/core/Collection.swift):
The declaration of _Element and subscript here is a trick used to break a cyclic conformance/deduction that Swift can't handle. We need something other than a CollectionType.Generator.Element that can be used as IndexingGenerator<T>'s Element. Here we arrange for the CollectionType itself to have an Element type that's deducible from its subscript. Ideally we'd like to constrain this Element to be the same as CollectionType.Generator.Element, but we have no way of expressing it today.
Related
I have put together what should have been a simple piece of sample in an Xcode 8β2 playground. Unfortunately, I can't see why the struct does not conform to the protocol. I'm sure it's something very simple but can't, for the life of me, see it.
protocol ProtoStack {
associatedtype ItemType
func push(item: ItemType)
func pop() -> ItemType
func isEmpty() -> Bool
func size() -> Int
}
struct MyStack: ProtoStack {
var contents = [Int]()
typealias ItemType = Int
mutating func push(item: Int) { contents.append(item) }
mutating func pop() -> Int { return contents.popLast()! }
func isEmpty() -> Bool { return contents.count == 0 }
func size() -> Int { return contents.count }
}
In order to conform to your ProtoStack protocol as it's currently written, your push and pop methods in your MyStack can't be mutating, as you cannot satisfy a non-mutating protocol requirement with a mutating struct/enum method. Therefore if you want these methods to be mutating, then you also need to mark them in the protocol as being so.
As the Swift language guide says (emphasis mine):
If you define a protocol instance method requirement that is intended to mutate instances of any type that adopts the protocol, mark the method with the mutating keyword as part of the protocol’s definition. This enables structures and enumerations to adopt the protocol and satisfy that method requirement.
A mutating method in a protocol requirement can either be satisfied by a mutating1 instance method in a value type (e.g a struct or enum) or a regular instance method in a class, as class instances can be mutated freely.
1. A mutating protocol requirement can also be satisfied by a non-mutating method in a value type, as this doesn't break the contract with the protocol (nothing depends on a mutation actually taking place within that method).
I have created my custom sequence type and I want the function to accept any kind of sequence as a parameter. (I want to use both sets, and my sequence types on it)
Something like this:
private func _addToCurrentTileset(tilesToAdd tiles: SequenceType)
Is there any way how I can do it?
It seems relatively straightforward, but I can't figure it out somehow. Swift toolchain tells me:
Protocol 'SequenceType' can only be used as a generic constraint because it has Self or associated type requirements, and I don't know how to create a protocol that will conform to SequenceType and the Self requirement from it.
I can eliminate the associatedType requirement with, but not Self:
protocol EnumerableTileSequence: SequenceType {
associatedtype GeneratorType = geoBingAnCore.Generator
associatedtype SubSequence: SequenceType = EnumerableTileSequence
}
Now if say I can eliminate self requirement, then already with such protocol definition other collectionType entities like arrays, sets won't conform to it.
Reference:
my custom sequences are all subclasses of enumerator type defined as:
public class Enumerator<T> {
public func nextObject() -> T? {
RequiresConcreteImplementation()
}
}
extension Enumerator {
public var allObjects: [T] {
return Array(self)
}
}
extension Enumerator: SequenceType {
public func generate() -> Generator<T> {
return Generator(enumerator: self)
}
}
public struct Generator<T>: GeneratorType {
let enumerator: Enumerator<T>
public mutating func next() -> T? {
return enumerator.nextObject()
}
}
The compiler is telling you the answer: "Protocol 'Sequence' can only be used as a generic constraint because it has Self or associated type requirements".
You can therefore do this with generics:
private func _addToCurrentTileset<T: Sequence>(tilesToAdd tiles: T) {
...
}
This will allow you to pass in any concrete type that conforms to Sequence into your function. Swift will infer the concrete type, allowing you to pass the sequence around without lose type information.
If you want to restrict the type of the element in the sequence to a given protocol, you can do:
private func _addToCurrentTileset<T: Sequence>(tilesToAdd tiles: T) where T.Element: SomeProtocol {
...
}
Or to a concrete type:
private func _addToCurrentTileset<T: Sequence>(tilesToAdd tiles: T) where T.Element == SomeConcreteType {
...
}
If you don't care about the concrete type of the sequence itself (useful for mixing them together and in most cases storing them), then Anton's answer has got you covered with the type-erased version of Sequence.
You can use type-eraser AnySequence for that:
A type-erased sequence.
Forwards operations to an arbitrary underlying sequence having the same Element type, hiding the specifics of the underlying SequenceType.
E.g. if you will need to store tiles as an internal property or somehow use its concrete type in the structure of you object then that would be the way to go.
If you simply need to be able to use the sequence w/o having to store it (e.g. just map on it), then you can simply use generics (like #originaluser2 suggests). E.g. you might end up with something like:
private func _addToCurrentTileset<S: SequenceType where S.Generator.Element == Tile>(tilesToAdd tiles: S) {
let typeErasedSequence = AnySequence(tiles) // Type == AnySequence<Tile>
let originalSequence = tiles // Type == whatever type that conforms to SequenceType and has Tile as its Generator.Element
}
If I have two protocols whose associated type happens to be the same, such as
protocol Read {
associatedtype Element
func read() -> Element
}
protocol Write {
associatedtype Element
func write(a: Element)
}
Then I would like to have a class to read integer from and write string to:
class ReadWrite: Read, Write {
func read() -> Int {
return 5
}
func write(a: String) {
print("writing \(a)")
}
}
but the compiler complains and suggests changing String to Int. Ideally the type should be inferred, or at least compiles if I explicitly declare
associatedtype Read.Element = Int
associatedtype Write.Element = String
within ReadWrite. Any work around?
update
Workaround inspired by this question is to create two auxiliary protocols
protocol ReadInt: Read {
associatedtype Element = Int
}
protocol WriteString: Write {
associatedtype Element = String
}
and have the class inherit from these two instead:
class ReadWrite: ReadInt, WriteString {
func read() -> Int {
return 5
}
func write(a: String) {
print("writing \(a)")
}
}
This seems to compile, but I am afraid of any gotcha following this way.
update again
I found the issue in Swift's issue tracker. Anyone require this missing feature (like me) should vote for it. As a comparison, this pattern is possible in Rust, which also supports associated types (although this is not an idiomatic usage).
Another workaround is to create a third, combined protocol:
protocol ReadWrite {
associatedtype R
associatedtype W
func read() -> R
func write(a: W)
}
It's not pretty, since it forces you to redeclare the protocol members, but it does keep it generic (you're not limited to String and Int).
I'm trying to implement a protocol that conforms to/extends CollectionType, however it doesn't take a single generic type that would obviously be the type of element, so I'd like to be able to compute/force the type of Generator.Element.
I'll use a map protocol as an example:
protocol Map : CollectionType {
typealias Key
typealias Value
subscript(key:Key) -> Value? { get }
}
Is there a way that I can specify that Self.Generator.Element must be (Key, Value), other than documentation to type authors?
You want to define a subprotocol of CollectionType with additional constraint on CollectionType.Generator.Element nested type. This nested type belongs to CollectionType.Generator nested type which is constrained to be GeneratorType, so in the first place we need to introduce a subprotocol of GeneratorType with additional constraint:
protocol KeyValueGeneratorType: GeneratorType {
associatedtype Key
associatedtype Value
mutating func next() -> (Key, Value)?
}
Then we can introduce a subprotocol of CollectionType with additional constraint:
protocol KeyValueCollectionType: CollectionType {
associatedtype Generator: KeyValueGeneratorType
}
The Dictionary type does in fact conform to our protocol, so we need just a short declaration to manifest this:
extension DictionaryGenerator: KeyValueGeneratorType {}
extension Dictionary: KeyValueCollectionType {}
You have to create the type of generator element you want to conform to. For example.
protocol SpecialElement {
typealias key : Int { get }
typealias Value : Int { get }
}
And then:
extension CollectionType where Self.Generator.Element: SpecialElement {
func addValues() -> Int {
var total = 0
for item in self {
total += item.Value
}
return total
}
}
In the Swift programming guide from Apple, it is described how to use the typealias keyword within protocols (from the section on Generics)
protocol Container {
typealias ItemType
mutating func append(item: ItemType)
var count: Int { get }
subscript(i: Int) -> ItemType { get }
}
which is then implemented:
struct IntStack: Container {
typealias ItemType = Int // can sometimes be left out and inferred by the compiler
mutating func append(item: Int) {
self.push(item)
}
// redacted
}
However, a significantly different use case is found in the Swift standard lib, e.g
public protocol ForwardIndexType : _Incrementable {
typealias Distance : _SignedIntegerType = Int
// redacted
}
or
public protocol CollectionType : Indexable, SequenceType {
typealias Generator : GeneratorType = IndexingGenerator<Self>
public func generate() -> Self.Generator
// redacted
}
together with:
extension CollectionType where Generator == IndexingGenerator<Self> {
public func generate() -> IndexingGenerator<Self>
}
What does this syntax represent? It appears that the typealias is both declared, restricted (e.g. to GeneratorType) and assigned, all at once? What does this mean and why is it so? I expected to see assignment (=) only in implementing client code.
My understanding of typealias is that it represents a type, that is 'filled in' by the implementing code (as per generics) yet here it seems to implement a type for the typealias in the declaration, even though this is also done in the extension (where I would expect it).
Take a look at this answer. Use of a colon shows inheritance, use of an equals sign shows assignment.
In my understanding this means the following:
typealias X // defines associated type X for subclasses to override
typealias X: Y // defines associated type X and requires that it conform to Y
typealias X = Z // defines associated type X with a default of type Z
typealias X: Y = Z // defines associated type X with a default of type Z and requires that any overrides conform to Y
My interpretation seems to be supported by this article on Swift generics:
An associated type is declared by a protocol using the typealias
keyword. It normally set by an item that conforms to that protocol,
although you can supply a default. Like type parameters, an
associated type can be used as a token when building generic type
rules.
The use of the keyword typealias can be misleading for defining associated types and may be replaced by associatedtype in the future.