New workaround needed for the "non-fixed multi-payload" bug

[bkase]

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.

[Thomvis]

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!

[Thomvis]

I just pushed the compatibility update consisting of commits 16e32bd and 8e280e4. Let me know what you think!

Also, the tests don't run for me. They just hang there. Does that happen for you as well?

[bkase]

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 (printlns in the Promise constructor do not appear in the log)

There must be a regression in this beta.

[bkase]

Even just creating a promise in a test case causes a hang (before any constructor code is run)

[bkase]

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

[Thomvis]

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

[bkase]

Awesome, hopefully Apple will fix this fast

[bkase]

Apple fixed the hanging bug in Beta7 (Thank goodness!)

All the unit-tests pass now

[Thomvis]

That's great news! Still no word on the non-fixed layout enums though...

[Thomvis]

Like everybody, we're still boxing the success value in Result and it's fine for now. Closing this issue.