Alamofire: internal Result type conflicts with Result external dependency

[itchingpixels]

Hi,

We come across this issue where you won't be able to do this inside a project that has both Alamofire and Result framework:

import Alamofire
import Result

The compiler will start immediately complaining about Result being an ambiguous type.

Is there any reason why Result is not decleared as a dependency? Would it be possible to move it inside the "Alamofire" class, to namespace it?

Thanks a lot!

[cnoon]

We will not be adding a dependency to Alamofire @itchingpixels. This issue has already been discussed in detail in #764 and #1072.

Cheers. 🍻

[itchingpixels]

@cnoon I understand your concern, but the number of issues people have opened because of exactly the same problem indicates that this is actually a problem of the users of Alamofire.

I've looked through the linked issues, and I understand that Alamofire wouldn't like to:

• Add 3rd party dependency to its projects
• Rename a struct to be something less descriptive

Has it been considered to namespace the Result struct?
All that would take is to move its definition inside the Alamofire class:

extension Alamofire {
  struct Result {
   ... definition goes here
  }
}

This would avoid both of your original concern, and it would also make it explicit that Alamofire uses its own Result implementation, and not the one that the community is otherwise familiar with.

Unfortunately Swift has its limitations at the moment, and we were promised to abandon namespacing completely, but in real life, it does cause issues. It would be very considerate of you guys if a utility data structure, that many people use in their own projects would be named by keeping these limitations in mind.

[jshier]

@itchingpixels All Swift frameworks are automatically namespaced. You can disambiguate by using Alamofire.Result or Result.Result already. Now, if you aren't using your dependencies as frameworks, there's not much we can do to help you, as frameworks are Swift best practice for independent dependencies.

[cnoon]

Thanks @jshier, well said.

@itchingpixels, we won't make the Result type more difficult to work with in any way for users that aren't using a second Result type that conflicts. You MUST understand that point of view. You're suggestions are attempting to make your use case easier without considering the effect it would have on the community. For those not familiar with the antitypical/Result library, the Alamofire design would seem very odd.

We're always open to suggestions to make Alamofire better, but it must be better for the community. Not for individuals. Adding a third party dependency to Alamofire that we don't control is certainly not in the best interest of the community. Renaming Result to something not result is not in the best interest of the community. Wrapping an additional extension around Result is not in the best interest of the community.

Are you planning on telling every third party library out there that they can't create their own Result type? It just doesn't seem realistic, nor considerate. This is a common pattern that the Swift community needs to use in various places, especially when async operations are involved. Most likely, these libraries will be creating their own Result types, unless they decide to couple to one of the Result libraries out there. But if they choose one that isn't the one you're using, you still have the same problem.

Please take @jshier's advice and use namespacing when you're working with both types. You could also consider not trying to use the two together.