Compiles in Xcode 10.2 but not Fire/Silver, what I am doing wrong?

(wdb) #1

IDE: Fire
Version: Version 10.0.0.2398 (develop) built on talax, 20190426-081224. Commit f04dec1.
Target (If relevant): iOS/macOS
Description:
Fail to compile Swift code that works fine in Xcode 10.2

Expected Behavior:
Code to compile successfully

Actual Behavior:
Getting the following compiler errors:

E:                Associated type "Value" from protocol "CellType<Value>" was not set [/Users/x/Desktop/Bug/BugReport3/ConsoleApplication3/Program.swift (58)]
E:                Unknown type "Cell.Value" [/Users/x/Desktop/Bug/BugReport3/ConsoleApplication3/Program.swift (54)]
                  -> Phase Resolving Bodies started.
E:                   Unknown type "Cell.Type", did you mean "CellType"? [/Users/x/Desktop/Bug/BugReport3/ConsoleApplication3/Program.swift (55)]
E:                   Generic parameter doesn't fulfill constraint "CellType<Value>" for "Cell" [/Users/x/Desktop/Bug/BugReport3/ConsoleApplication3/Program.swift (65)]
E:                   Generic parameter doesn't fulfill constraint "Equatable" for "Value" [/Users/x/Desktop/Bug/BugReport3/ConsoleApplication3/Program.swift (55)]

Steps:

  1. Create a new console application
  2. Use the code
import Foundation

open class BaseCell: NSObject {
}

/// Generic class that represents the Eureka cells.
open class Cell<T>: BaseCell {
    public typealias Value = T
}

open class BaseRow: NSObject {
    /// String that uniquely identifies a row. Must be unique among rows and sections.
    public var tag: String?

    public required init(tag: String? = nil) {
        self.tag = tag
    }
}

open class RowOf<T>: BaseRow {
    private var _value: T?
    open var value: T? {
        set (newValue) {
            _value = newValue
        }
        get {
            return _value
        }
    }

    public required init(tag: String?) {
        super.init(tag: tag)
    }
}

public protocol CellType: class {
    associatedtype Value: Equatable
}

open class LabelValueObject: Equatable {
    public static func == (lhs: LabelValueObject, rhs: LabelValueObject) -> Bool {
        return true
    }
}

open class Row<Cell: CellType>: RowOf<Cell.Value> where Cell: BaseCell {
    public let cellType: Cell.Type! = Cell.self
}

open class LabelCellOf<T: Equatable>: Cell<T>, CellType {

}
public typealias LabelCell = LabelCellOf<LabelValueObject>

// MARK: LabelRow

open class _LabelRow: Row<LabelCell> {
    required public init(tag: String?) {
        super.init(tag: tag)
    }
}

print("The magic happens here.")
(marc hoffman) #2

Weyert,

FWIW: less generic thread names will help us keep track off actual issues better. the title of this thread could be applied to any of your posts form this week, so that’s not really helpful (also for others looking for solutions to the same problem).

Looking at the issue now.

1 Like
(marc hoffman) #3
open class Row<Cell: CellType>: RowOf<Cell.Value> where Cell: BaseCell { // E28 Unknown type "Cell.Value"

ok, I don’t see Value defined anywhere. what’s that supposed to refer to? What is this code trying to accomplish?

	public let cellType: Cell.Type! = Cell.self // E548 Unknown type "Cell.Type", did you mean "CellType"?

this, I believe, we currently to not support. Type is a meta class (sort of like class of in Oxygene) and generating these for all types would generate a huge overhead. That said, once again I’m unsure what this code is trying to accomplish, though…

1 Like
(RemObjects) #4

Thanks, logged as bugs://82473

(wdb) #5

Sorry, didn’t really know how to title this topic :slight_smile:

1 Like
(wdb) #6

My understanding is the Value should or defines the type LabelValueObject as the line is:

public typealias LabelCell = LabelCellOf<LabelValueObject>

It’s code from the Eureka form framework for iOS/Swift which I have been trying to compile with Fire/Silver. I have to admit I don’t 100% understand what’s going on hence don’t know if this is actual something that will be supported by Silver.

(RemObjects) #8

bugs://82473 got closed with status notfixable.

(wdb) #9

Would it potentially be fixable in Toffee v2?

(Carlo Kok) #11

Nothing in Toffee V2 will fix this specifically no since Toffee V2 is a backend. To do this we need to vastly change how generics work internally and I haven’t found a way to make this work yet.