On Aug 18, 2017, at 11:56 AM, David Beck <[email protected]> wrote:
> ## Conversion of imported Objective-C APIs
> 
> One issue I see with the importer is that the conventions for callbacks 
> aren’t as strict as NSError ** methods were. For instance, URLSession 
> completion blocks include response, data and error, all of which are 
> optionals. The response is almost always present, even if there was an error. 
> But there is no way to know that from the ObjC type system, and no way to 
> represent a throwing function that also returns metadata on error in Swift.

Sure, the default would be to import these as just a bunch of optionals.  
Something better could be done on a case by case basis (in overlays) though.

> 
> How should we represent dataTask(with:completion:)?

Someone else brought this up.  The most conservative thing is to leave it as a 
completion handler, and only transform void-returning ObjC methods.

> ## Actors
> 
> I fail to see the benefit of adding an entirely new construct for the actor 
> model. It seems like access control, value semantics, and dispatch queues 
> largely fill this need already, and the implimentation of an actor wouldn't 
> be so complicated currently that it needs a compiler feature to ensure a 
> correct implimentation.

It really comes down to whether you think elimination of shared mutable state 
is worth it, and if you think that having a higher level answer for concurrency 
is worth it.  Reasonable people can differ on this, and I expect opinions to 
vary, because GCD and other existing things are pretty good.  I think we can 
aim higher though.

-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to