Anyone encounter the `@ShouldRefineInSwift` annota...

# ios

[Sam]

Anyone encounter the @ShouldRefineInSwift annotation making the method disappear entirely? The method disappears, but no __-prefixed version appears (I know it won't show in autocomplete, but it produces an error if I try writing it anyway).

Currently working around by doing @ObjCName("__method"), which is almost as good, just pollutes autocomplete.

[Anonymike]

For me none of the @ObjCName properties generated by KMP Native Coroutines autocomplete at all and I get a red line as if its an error though the code compiles and works. I'll try it outside of the generated methods and see if I see the same result as you but it would be great if all my viewmodel properties actually autocompleted. I honestly don't know if its a known issue currently or if it is supposed to work with autocomplete.

[Sam]

Hmm... I use KMP Native Coroutines and haven't had an issue... but maybe I just haven't tried calling any generated members yet. I've only used the createPublisher(for:) Combine function.

[Chris Mulder]

Is it a suspend function by any chance? Noticed that the WithCompletionHandler suffix is added. You can always check the generated header file for the hidden method names

[Sam]

Not in my case, but that might explain Anonymike's issue

[Anonymike]

In my case, the odd thing is that (for us) autocompletion works great with suspension functions marked with @NativeCoroutines, but not any properties (Mutable / NonMutable State Flows, etc.) with the code that KMPNativeCoroutines generates for them, including the IDE marking them as an error in Swift code. I'm still figuring out ways to dig deeper and will report back if I find anything. Do your mutable state flows and @NativeCoroutines properties autocomplete or at least show as valid for you?

[Sam]

I always follow the “private mutable flow, public `asStateFlow()`” pattern, but yeah if I mark a flow as native I can find it in Swift just fine. In fact that’s been my only use case so far.

[Anonymike]

Thanks for mentioning that!

Ill try that out and see if it is in fact the difference. If so its hopefully an easy pull request or issue to improve the library. I dont mind the orivate public but it is extra boilerplate on a lot of properties and sometimes we do need to go both ways. Perhaps there is a good way to use a delegate here and accomplish the read only exposure.

On Thu, Mar 30, 2023, at 8:42 AM, Slack wrote:

You have new messages in kotlinlang (kotlinlang.slack.com)

From a thread in #ios  

Sam   March 30th at 8:38 AM

I always follow the “private mutable flow, public `asStateFlow()`” pattern, but yeah if I mark a flow as native I can find it in Swift just fine. In fact that’s been my only use case so far.

Open in Slack

Slack <[e-mail]?subject=Reply to thread in #ios|Reply>

Manage your notifications

Snooze them for an hour, eight hours, a day, three days, or the next week. Or, turn email notifications off. For more detailed preferences, see your account page.

Workspace name: kotlinlang

kotlinlang

Workspace URL: kotlinlang.slack.com

Email: [e-mail]

Sign In

Our Blog   |   Policies   |   Help Center   |   Slack Community

©2023 Slack Technologies, LLC, a Salesforce company.

415 Mission Street, San Francisco, CA 94105

All rights reserved.