Skip to content
This repository has been archived by the owner on Aug 10, 2021. It is now read-only.

Unit bridges to KotlinUnit in Swift escaping closures #2549

Closed
benasher44 opened this issue Jan 16, 2019 · 5 comments
Closed

Unit bridges to KotlinUnit in Swift escaping closures #2549

benasher44 opened this issue Jan 16, 2019 · 5 comments

Comments

@benasher44
Copy link
Contributor

For functions/closures that return KotlinUnit in Swift, you get a warning about an unused result, which isn't ideal.

In kotlin, this return type is used as Void in Swift (void in C/Obj-C). I'm having trouble locating such an attribute, but ideally there'd be a way to attribute this return value in the Obj-C header as discardable (i.e. the @discardableResult Obj-C equivalent). If there are other ways to improve this situation, those would also be nice. Thanks!

@benasher44
Copy link
Contributor Author

Actually, this might be a bug? According to the interop doc, unit should bridge to void: https://kotlinlang.org/docs/reference/native/objc_interop.html

@benasher44 benasher44 changed the title [Feature Request] Improve usage of KotlinUnit in Swift Unit bridges to KotlinUnit in Swift escaping closures Jan 25, 2019
@j0bro
Copy link

j0bro commented Mar 25, 2019

This is still the case in K/N 1.3.21, would be great if one could just return Void in Swift instead of the unnecessary KotlinUnit currently.

@RockLobster
Copy link

Unfortunately, the function types section specifically mentions that function types are treated different than regular functions and seems intentional.

We are developing a library and the fact that we have to leak to users of our library that we are using Kotlin under the hood is not very nice. Not to speak of the fact that people are forced to type return KotlinUnit() for every call.

@galex
Copy link

galex commented Apr 16, 2019

It is indeed a hard sell to iOS developers in my company and might not be taken seriously just because it adds noise.

@SvyatoslavScherbina
Copy link
Collaborator

Improved with #2968. Will likely be shipped within 1.3.40.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants