New workaround needed for the "non-fixed multi-payload" bug
bkase opened this issue · comments
In Xcode Beta 6, compiling BrightFutures gives the following error:
'__conversion' functions are no longer allowed
It looks like there is not another way to do an implicit type conversion to workaround the .Success value in the TaskResult enum. Unfortunately, writing the code as it should be written:
public enum TaskResult<T> {
case Success(T)
case Failure(NSError)
...
}
still results in an "unimplemented IR generation feature non-fixed multi-payload enum" error.
I think it is necessary to expose the unboxing of the generic value to users of the API, but I didn't want to make a pull-request in case you had a good solution.
Yes, I was just working on a 'fix'. I basically see no fix other than just expose the (un)boxing. Luckily, the exposure to the unboxing for users of the Futures is limited to onComplete
. onSuccess
and onFailure
can do the unboxing for the user and in most cases I think these callbacks are preferred anyway. I will push a compatibility update shortly. I hope that before version 1.0 they fix the enum thing.
Thanks for your feedback!
That does happen to me as well.
It looks like the code hangs on the call to the Promise<T>()
constructor in the top-level future<T>
function in Future.swift
.
The constructor is never being called (println
s in the Promise constructor do not appear in the log)
There must be a regression in this beta.
Even just creating a promise in a test case causes a hang (before any constructor code is run)
This causes the hang ( https://gist.github.com/bkase/847351601b8c3a3df99d )
import Foundation
public class A<T> {
var callbacks: [A<T> -> ()] = []
public init() {
}
}
and from somewhere that imports the framework
let x: A<Int> = A()
That line of code hangs and the constructor code never executes
Thanks for figuring that out! This is a nasty regression. I think it has something to do with recursive generic types, i.e. the implementation of A refers to A.
I could reduce the failing example to the following:
public class A<T> {
var callbacks: A<T>?
}
A<Int>()
I'll file a radar with that.
Update: here's the radar http://openradar.appspot.com/radar?id=6427467279499264
Awesome, hopefully Apple will fix this fast
Apple fixed the hanging bug in Beta7 (Thank goodness!)
All the unit-tests pass now
That's great news! Still no word on the non-fixed layout enums though...
Like everybody, we're still boxing the success value in Result and it's fine for now. Closing this issue.