While experimenting with generics in Swift I came across this problem and am not able to find an answer.
Say I have the following code:
protocol Component {
}
protocol Contains {
associatedtype CompType: Component
var components: [CompType] { get set }
}
Here, types that implement Contains should be able to store any type that implements the Component protocol specified by their typealias. If I extend the code to the following, it works as expected.
protocol Component {
}
struct SomeComponent: Component {
init() {
}
}
struct AnotherComponent: Component {
init() {
}
}
protocol Contains {
associatedtype CompType: Component
var components: [CompType] { get set }
}
struct Container: Contains {
typealias CompType = SomeComponent
var components: [SomeComponent]
}
var x = Container(components: [SomeComponent()]) // works perfectly!
var y = Container(components: [AnotherComponent()]) // fails as expected
Finally the question: is it possible to make Container.components accept both SomeComponent and AnotherComponent, but reject other types that implement the Component protocol? In other words, can typealias hold more that one type?
Thanks!
You can conform to multiple protocols
typealias CompType = SomeComponent & AnotherComponent
Or you can do changing logic
protocol Component {
}
struct SomeComponent: Component {
init() {
}
}
struct AnotherComponent: Component {
init() {
}
}
protocol Contains {
var components: [Component] { get set }
}
struct Container: Contains {
var components: [Component]
}
var x = Container(components: [SomeComponent()])
var y = Container(components: [AnotherComponent()])
The type alias serves to resolve the generic associated type. It must resolve it to one type unambiguously; that is what resolution is.
Well, the way you’ve set things up, that type can and must be any Component adopter. That is what this line means:
associatedtype CompType: Component
You used a generic constraint of Component. If that’s not what you wanted, you shouldn’t have set things up that way. As others have suggested, if you want just SomeComponent and AnotherComponent to satisfy the generic constraint, then you would need to use a protocol that only SomeComponent and AnotherComponent adopt.
I don't think you need the associatedtype at all
protocol Component {
}
struct SomeComponent: Component {
init() {
}
}
struct AnotherComponent: Component {
init() {
}
}
protocol Contains {
var components: [Component] { get set }
}
struct Container: Contains {
var components: [Component]
}
var x = Container(components: [SomeComponent()])
var y = Container(components: [AnotherComponent()])
Use associatedtype on protocols when you need to specify a type.
On this case you don't want to specify because you want to be able to accept a conformer to a protocol
Related
TL;DR
How can I conform to the supscript function of a protocol in my implementation?
Protocol:
protocol DataStore {
//...
subscript<T>(id: T.ID) -> T where T: Identifiable { get set }
}
Neither
subscript<T>(id: T.ID) -> T where T : Identifiable {
get { Project() }//just to return anything for the time being…
set {}
}
nor
subscript(id: Task.ID) -> Task {
get { Project() }//just to return anything for the time being…
set {}
}
work...
The details:
I have developed a habit of creating specific data stores for my models. They all have the same functionality. A specific example could look like this:
final class ProjectDataStore: ObservableObject {
{
static let shared = ProjectDataStore()
let persistence = AtPersistLocally.shared // that's from a personal package I made that handles saving and loading locally as json files
#Published var projects: [Project] {
didSet { //save }
}
private init(projects: [Project]? = nil) {
//load from persistence
}
subscript(id: Project.ID) -> Project? {
get { //return project with id }
set { //set project at id }
}
func getBinding(by id: Project.ID) -> Binding<Project> {
//return Binding
}
func getProjectBy(taskId: Task.ID) -> Project {
//return instance
}
private func getIndex(by id: Project.ID) -> Int? {
//return index in array
}
private func load() -> [Project] {
//load from persistence
}
private func save() {
//save from persistence
}
}
While this works as expected, I'd like to be able to introduce a protocol that I could when adding new functionality / models to have a blueprint on what's necessary for my DataStore.
Here is my first attempt:
protocol DataStore {
static var shared: Self { get }
}
extension DataStore {
var persistence: AtPersistLocally {
get {
AtPersistLocally.shared
}
}
}
To also conform to ObservableObject, I introduce a typealias
typealias ObservableObjectDataStore = DataStore & ObservableObject
and change my model to conform to this new typealias:
final class ProjectDataStore: ObservableObjectDataStore {
//...
}
With this, I already have a static instance and access to persistence available.
Next step of course is to move more and more properties to the protocol–which is what I am struggling with right now.
Let's look at superscript first of all: I guess I understand what needs to be added to the protocol:
protocol DataStore {
//...
subscript<T>(id: T.ID) -> T where T: Identifiable { get set }
}
My problem now is that I don't know how to go about conforming to this subscript now while also getting access to a concrete model from the generic T from the implementation. This attempt…
final class ProjectDataStore: ObservableObjectDataStore {
//...
subscript<T>(id: T.ID) -> T where T : Identifiable {
get { Project() }//just to return anything for the time being…
set {}
}
}
…leads to the error message Cannot convert return expression of type 'Task' to return type 'T'.
If I go with…
final class ProjectDataStore: ObservableObjectDataStore {
//...
subscript(id: Task.ID) -> Task {
get { Project() }//just to return anything for the time being…
set {}
}
}
…the error message changes to Type 'TaskDataStore' does not conform to protocol 'DataStore'.
So I guess basically what I am asking is: how can I conform to my protocol's generic superscript in my implementation of ProjectDataStore?
I have a feeling that I am not too far of, but a critical info is obviously missing…
subscript<T>(id: T.ID) -> T where T: Identifiable { get set }
This says that the caller may pick any Identifiable T, and this method promise return a value of that type. This can't be implemented (other than calling fatalError() and crashing). Identifiable doesn't even promise that the type has an init. Your protocol is impossible.
What you probably meant to write is, which says that a given DataStore will return some specific Identifiable type (not "whatever type the caller requests"):
protocol DataStore {
associatedType Item: Identifiable
subscript(id: Item.ID) -> Item { get set }
}
But I expect this would be much better implemented without a protocol, and just use a generic struct:
struct DataStore<Item: Identifiable> { ... }
I have a protocol extension which declares and assigns a static computed variable:
protocol DataType {
}
extension DataType {
static var mocks: [Self] { [] }
}
Then I have another protocol named Provider which has an associatedtype requirement of the DataType protocol and an extension:
protocol Provider {
associatedtype Data: DataType
}
extension Provider {
static var mock: [Data] {
Data.mocks
}
}
I then create the following types that conform to DataType and Provider:
struct Car: DataType {
var name: String
static var mocks: [Car] {
[.init(name: "Nissan"), .init(name: "Toyota")]
}
}
struct CarProvider: Provider {
typealias Data = Car
}
print(CarProvider.mock)
When I print this out (an empty array []), the CarProvider static variable mock prints out the default value of the mocks variable of DataType - even when Car has an assigned array value for mocks inside its struct definition
However, as soon as I declare the mocks property inside the DataType protocol as a requirement, then the mocks value of Car is correctly read (printing the correct values: [__lldb_expr_93.Car(name: "Nissan"), __lldb_expr_93.Car(name: "Toyota")]):
protocol DataType {
static var mocks: [Self] { get }
}
Why is the property definition required in the Protocol definition in the first place? Shouldn't the extension value be sufficient? And since the Car struct is assigning its own value to the mocks variable, shouldn't that be read instead of the default extension value?
Why is the property definition required in the Protocol definition in
the first place? Shouldn't the extension value be sufficient?
No. An implementation in a protocol extension can only be considered a true default implementation, if there is some way for it to be overridden in scope. Without having the requirement in the protocol, Swift has no reason or mechanism to look beyond an extension, because there's nothing else that will match, semantically.
protocol DataType { }
extension DataType {
static var mocks: [Self] { [] }
}
func mocks<Data: DataType>(_: Data.Type) -> [Data] {
Data.mocks // This *is* the extension. That is the only truth.
}
protocol DataType {
static var mocks: [Self] { get }
}
extension DataType {
static var mocks: [Self] { [] }
}
func mocks<Data: DataType>(_: Data.Type) -> [Data] {
Data.mocks // Now, we can dispatch to a concrete `Data` type!
}
I'm trying to write a protocol that allows me to version models in my app. In order to do that I wrote the following VersionManager.
class VersionManager<Type: Decodable> {
private var database: Database
init(database: Database) {
self.database = database
}
var versions: [Type] {
return []
}
}
After that I wrote a protocol that I can add to models:
protocol Versionable {
}
extension Versionable {
private var manager: VersionManager<Restaurant> {
return VersionManager<Restaurant>(database: Database.shared)
}
public var versions: [Restaurant] {
return manager.versions
}
}
Now, the problem I'm facing is that I tried passing the type dynamically instead of hardcoded, like I have now for Restaurant.
So I tried changing the protocol to this:
protocol Versionable {
var kind: Decodable.Type { get }
}
Then I wanted to pass kind to VersionManager. However, when I try that Xcode throws this error: Expected '>' to complete generic argument list.
Is there any other way to do this?
If you want to use generics inside a protocol, you need to use an associatedtype
protocol Versionable {
associatedtype Model: Decodable
}
extension Versionable {
private var manager: VersionManager<Model> {
return VersionManager<Model>(database: Database.shared)
}
public var versions: [Model] {
return manager.versions
}
}
The model that is going to implement the Versionable protocol will have to resolve this type:
struct SomeModel: Versionable {
typealias Model = Int
}
SomeModel().versions // [Int]
I'm guessing Restaurant in your example refers to the model that implements Versionable. In that case, you can just use the Self reference inside your protocol extension:
protocol Versionable: Decodable {
}
extension Versionable {
private var manager: VersionManager<Self> {
return VersionManager<Self>(database: Database.shared)
}
public var versions: [Self] {
return manager.versions
}
}
struct SomeModel: Versionable {}
SomeModel().versions // [SomeModel]
Please note that the Versionable protocol now requires the Decodable conformance because of the VersionManager<Type: Decodable> generic constraint.
If I have a series of protocols like so:
protocol Customer {
var name:String { get set }
var age: Int { get set }
var startDate:Date { get set }
var meals:Array<String> { get set }
var market:Int { get set }
}
protocol Vegan:Customer {
}
protocol Vegetarian:Customer {
}
protocol Paleo:Customer {
}
and extension like so:
extension Customer where Self:Vegan, Self:Vegetarian {
func getMeals() -> Array<String> {
return ["VeganMeal1", "VeganMeal2", "VeganMeal3", "VeganMeal4"]
}
}
extension Customer where Self:Vegetarian {
func getMeals() -> Array<String> {
return ["VegetarianMeal1", "VegetarianMeal2", "VegetarianMeal3", "VegetarianMeal4"]
}
}
extension Customer where Self:Paleo {
func getMeals() -> Array<String> {
return ["PaleoMeal1", "PaleoMeal2", "PaleoMeal3", "PaleoMeal4"]
}
}
and this struct
struct aCustomer:Customer, Vegan {
var name:String
var age: Int
var startDate:Date
var meals:Array<String>
var market:Int
}
when I create a new object based on that struct
var newCustomer = aCustomer(name:"William", age:40, startDate:Date(), meals:[], market:1)
how come I can't access the getMeals function in the extensions? I get an error stating getMeals is an ambiguous reference.
extension Customer where Self:Vegan, Self:Vegetarian {
extends Customer in the case where the adopter or Customer also both adopts Vegan and Vegetarian. Your aCustomer (a struct type starting with a small letter?? the horror, the horror) does not do that, so the extension doesn't apply to it.
If the goal is to inject the same code either when the adopter adopts Vegan or when the adopter adopts Vegetarian, use two extensions, or, if you don't like the repetition, have them both adopt some "higher" protocol that is extended with the desired code to be injected.
I want to create an interface (protocol) for Tree in Swift. This tree will use interface (protocol) for TreeNodes. But all these interfaces should be generic. Ideally I want to have something like this:
protocol TreeNodeInterface {
associatedtype T: ElementInterface
var value: T { get set }
// ... some other methods
}
protocol TreeInterface {
var rootNode: TreeNodeInterface<T>? { get }
func clean()
// .. some other methods
}
class Tree<T: ElementInterface>: TreeInterface {
var root: TreeNodeInterface<T>?
var rootNode: TreeNodeInterface<T>? {
get {
return root
}
}
func clean() {
}
}
So for example I will have class Tree inherited from TreeInterface and I can initialize that Tree with any type (Int, String, CustomClass etc), so that each node will have that type as a value.
I managed to do this with Object Oriented Programming, but cannot do it with Protocol Oriented Programming
Swift doesn't allow me to do this. Can someone help me here?
Thanks
I think you're trying to do too much with protocols. Your biggest problem here is that you cannot create a variable with a protocol type if that protocol has an associated type (or a Self requirement). By replacing these definitions with generics, I ended up with this:
protocol TreeNodeInterface {
associatedtype Element: ElementInterface
var value: Element { get set }
// ... some other methods
}
protocol TreeInterface {
associatedtype Node: TreeNodeInterface
var rootNode: Node? { get }
func clean()
// .. some other methods
}
class Tree<T: TreeNodeInterface>: TreeInterface {
typealias Node = T
var rootNode: T?
init() {}
func clean() {
}
}
This compiles, but now you have to figure out how to initialize it. Next step is to make a type which conforms to TreeNodeInterface:
struct TreeNode<T: ElementInterface>: TreeNodeInterface {
typealias Element = T
var value: T
}
This looks strikingly similar to the protocol, but that's alright. Now let's initialize Tree:
// Assuming that Int conforms to ElementInterface
let tree = Tree<TreeNode<Int>>()
Phew! That was a lot of work, most of which I consider unnecessary. Do you really need TreeNodeInterface and TreeInterface? I'd argue that you don't. Here's what it might look like if you used concrete types instead:
struct TreeNode<T: ElementInterface> {
var value: T
}
class Tree<T: ElementInterface> {
var root: TreeNode<T>?
init() {}
func clean() {
}
}
let tree = Tree<Int>()