String behavior vs. partial classes

Elements Silver
1

Just noticed something:

I have a Silver shared project which defines:

public class A {

    private var someCompletion: ((String?) -> Void)?

}

I have a Silver/Toffee shared library (dylib) which builds upon this class using __partial:

import CoreBluetooth

public __partial class A {

     func someFunc(completion: (String?) -> Void) {
         someCompletion = completion
         // ...
     }

}

This gives me the following error:

"Type mismatch, expected “block ( param0: RemObjects.Elements.RTL.String?) -> Void”

I assume the compiler initially sees the first block definition and assumes it’s a RTL.String, which generates this error as it parses the 2nd chunk of the __partial class? I can work around the issue by importing Foundation in my shared project.

Am I understanding this properly?

2

Sounds like a bug, TBH, as the two String types should be compatible. Can you give me a complete testcase?

3

This reproduces the issue. It seems that as soon as I import Foundation (or some framework that imports Foundation) in the Silver/Toffee project, the error occurs.

StringBehaviour.zip (9.8 KB)

4

Thanks, logged as bugs://79832

5

bugs://79832 got closed with status fixed.

6

I confirm this is fixed in 2267.

1 Like
7

Getting a similar issue when the class is defined as such:

In shared project:

public class A {

    private var someHandler: ((String, String, Int) -> Void)?

}

in Cocoa dylib project:

public __partial class A {

    func someFunction(handler: (String, String, Int) -> Void) {
        someHandler = handler
    }

}

This goes away if I import Foundation in the shared project. There’s something different happening with closures (Carlo mentioned an issue in a private discussion last night but I don’t know if this is what he was referring to).

8

Thanks, logged as bugs://79873

9

bugs://79873 got closed with status fixed.

10

Confirmed as fixed in 2269. Thanks.

1 Like