Overloaded function showShareSheet causing compile problems with Swift

[willbattel]

Describe the bug

When trying to use showShareSheet in an async context, I'm getting compile errors Ambiguous use of 'showShareSheet(with:andShareText:from:)' and Type of expression is ambiguous without more context.

Steps to reproduce

This task works, but does not allow me to catch and react to the error.

Task {
    let buo = BranchUniversalObject(canonicalIdentifier: "myCanonicalIdentifier")
    let lp = BranchLinkProperties()
    let (activityType, completed) = await buo.showShareSheet(with: lp, andShareText: nil, from: self)
    let activity = try? await buo.showShareSheet(with: lp, andShareText: nil, from: self)
}

This task does not work.

Task {
    let buo = BranchUniversalObject(canonicalIdentifier: "myCanonicalIdentifier")
    let lp = BranchLinkProperties()
    let (activityType, completed) = await buo.showShareSheet(with: lp, andShareText: nil, from: self)
    do {
        let activity = try await buo.showShareSheet(with: lp, andShareText: nil, from: self)
    }
    catch {
        // Handle error
    }
}

Expected behavior

I expected to be able to call try await buo.showShareSheet(with: lp, andShareText: nil, from: self) such that I can handle the activity error. The only way Swift will accept showShareSheet in an async context is to drop the error and use the optional try? keyword instead of try.

I suspect that this problem is due to the fact that publicly exposed are two identical signatures for each variant of showShareSheet, one of each is marked async throws and the other async, such that Swift cannot determine which function is being used.

If I understand the API correctly, then it would seem that the proper solution is to remove the async functions, and keep only the async throws variants, which would allow the users of this SDK to determine if they want to handle the error or not. This would be a breaking change, requiring a major version bump.

SDK Version

2.2.0

XCode Version

14.3.1 (14E300c)

Device

N/A

OS

N/A

Additional Information/Context

No response

[echo-branch]

@willbattel
Thanks for pointing this out.

That API is defined in ObjC and it appears the automatic conversion of NSErrors in callbacks to Swift exceptions is causing Xcode some confusion. Going to log a ticket for this. It may be a bit before we get to it as most our attention is devoted to iOS 17 related tasks at the moment.

[github-actions]

This issue has been automatically marked as stale due to inactivity for 60 days. If this issue is still relevant, please respond with any updates or this issue will be closed in 7 days. If you believe this is a mistake, please comment to let us know. Thank you for your contributions.

[github-actions]

This issue has been closed due to inactivity. If this issue is still relevant, please reopen it or create a new one. Thank you for your contributions.