https://kotlinlang.org logo
#touchlab-tools
Title
# touchlab-tools
j

Jon Bailey

02/21/2024, 6:52 PM
Hi, currently if passing in a non optional value into onEnum(of:) and storing the result in an optional field, there is ambiguity between the two generated
onEnum(of:)
functions. Would it be possible to add
@_disfavoredOverload
to the optional one?
f

Filip Dolník

02/22/2024, 1:33 PM
Hi! I will look into it. This particular use case wasn’t something we considered when we designed and tested the function so we were under the impression that it will not cause such conflicts. My first thought is that using
@_disfavoredOverload
isn’t ideal and I want to look for other options first. This attribute is unstable and the docs explicitly mentions that it should only be used for workarounding compiler bugs which I’m not sure is this case.
j

Jon Bailey

02/22/2024, 4:19 PM
The ambiguity is in this case:
Copy code
let kotlin: SharedSealedClass = ..
	let swift: Skie.Features.SharedSealedClass.__Sealed? = onEnum(of: kotlin)
And yep it’s a bit unsettling that it’s underscored but SwiftUI uses it for the Text view so it’s not unused. https://forums.swift.org/t/how-to-determine-if-a-passed-argument-is-a-string-literal/41651 (from https://www.fivestars.blog/articles/disfavoredOverload/) Otherwise a third onEnum(of:) would be able to fix the ambiguity without the use of disfavoredOverload
I think it’s fairly common to use nullable enums as SwiftUI State but it could just be me :)
f

Filip Dolník

02/22/2024, 5:52 PM
yeah, I think that the use case is not that unreasonable to not be supported, so that’s not the problem. I just need to find the best solution.