search

Swinject / SwinjectAutoregistration

Swinject extension to automatically register your services
MIT License
251 stars 45 forks source link

Operator API breaking change #26

Closed tkohout closed 7 years ago

tkohout commented 7 years ago

While writing tests for operators I've noticed there is ambiguity when calling ~> infix operator with named service and 2 arguments:

let s = container ~> (Service2.self, name: "MyService2", arguments: "Arg1", 5)

Compiler is not sure whether to call:

func ~> <Service, Arg1, Arg2>(r: Resolver, o: (Service.Type, name: String, arguments: Arg1, Arg2) ) -> Service

or

func ~> <Service, Arg1, Arg2, Arg3>(r: Resolver, o: (Service.Type, arguments: Arg1, Arg2, Arg3) ) -> Service

The problem is, tuple - unlike function call does not infer argument names, so above call just becomes (Service2.Type, String, String, Int) and compiler is confused. I believe this change arrived in swift 3, we just didn't noticed because there were not tests for it.

So to break this ambiguity, I changed the api to use tuple in the arguments:

let s = container ~> (Service2.self, name: "MyService2", arguments: ("Arg1", 5))

This is obviously not ideal as it breaks away from the Swinject resolve api, but I don't see any other solution.

I wanted to make this non-breaking change and deprecate the old api but its signature is again interfering with the new one and I had to remove a call with two arguments.

I welcome any feedback on this one.

tkohout commented 7 years ago

Since there is no feedback, I'm merging this.

yoichitgy commented 7 years ago

I completely missed the pull request. Sorry😱