A modern programming language that makes developers happier.

kotlinlang

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?

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.

The ambiguity is in this case:
```	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|https://forums.swift.org/t/how-to-determine-if-a-passed-argument-is-a-string-literal/41651> (from <https://www.fivestars.blog/articles/disfavoredOverload/|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 :) 

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.

Fixed in <https://skie.touchlab.co/changelog/0.6.2>