Xcode 13 issue - Enum cases with associated values cannot be marked potentially unavailable with '@available'

SwiftKickMobile / SwiftMessages

A very flexible message bar for UIKit and SwiftUI.

MIT License

7.24k stars 741 forks source link

Xcode 13 issue - Enum cases with associated values cannot be marked potentially unavailable with '@available' #471

Closed rizwan95 closed 2 years ago

rizwan95 commented 3 years ago

When we try to build SwiftMessages with Xcode 13 beta, the following error is being thrown: Enum cases with associated values cannot be marked potentially unavailable with '@available'

dneykov commented 3 years ago

Seems like a bug in Swift 5.5

https://bugs.swift.org/browse/SR-14539

wtmoose commented 3 years ago

I'll keep an eye on this. Hopefully, they'll fix the bug!

rizwan95 commented 3 years ago

@wtmoose @dneykov There is no activity in the bug report after it was reported or am I missing anything??

racsol commented 3 years ago

Hi, do you have any hopes for the bug to be fixed by apple before iOS 15 release? the bug SR-14539 is marked as "Improvement" and without any activity for a long time...

wtmoose commented 3 years ago

@racsol I have no idea

rizwan95 commented 3 years ago

My intuition says that Apple won't fix the bug sooner. What do we do?

ymkim50 commented 3 years ago

I temporarily downloaded the source. And set Platform in Package.swift

platforms: [ .iOS ("13.0") ],

And added it as a Local Package. After that, no error occurred.

This is a temporary method.

rizwan95 commented 3 years ago

I temporarily downloaded the source. And set Platform in Package.swift

platforms: [ .iOS ("13.0") ],

And added it as a Local Package. After that, no error occurred.

This is a temporary method.

Yes that is one hackish solution...

eigenl commented 3 years ago

Asked the author of that change about it: https://twitter.com/slava_pestov/status/1409910935347732489?s=20

In short, the code needs to be updated not to require @available

edit: deleted brainfart

wtmoose commented 3 years ago

LOL...I'm not sure his suggestion would qualify as a workaround.

wtmoose commented 3 years ago

@eigenl It seems you're trying to suggest a compile-time check but available is a run time thing. The code you're written if #available...#else isn't valid syntax and wouldn't compile.

If they're actually not going to fix this, then the only options I see are (a) make a breaking API change in SwiftUI or (b) stop supporting iOS 12 and below.

I'm inclined to take option (b).

eigenl commented 3 years ago

Yeah, sorry for the brainfart. Removed it. Another passable solution would be

case windowScene(_: Any, windowLevel: UIWindow.Level)

and casting the associated value to UIWindowScene where needed (just one location in SwiftMessages.Config+Extensions.swift).

This does remove compile-time guarantee but requires no changes to applications and is the smallest change that could be made to fix it I believe. Dropping iOS 12 is certainly an option, but poses a problem for application developers where decisions regarding minimum targets are out of their hands.

rizwan95 commented 3 years ago

I suppose the solution proposed by @eigenl should be good enough. What are your thoughts @wtmoose ? We need to act quick or else there will be many projects breaking due to this issue

gereons commented 3 years ago

I reported the same issue in https://bugs.swift.org/browse/SR-14878 and that was just closed as "works as designed". Bummer.

racsol commented 3 years ago

Any plans on fixing this issue? It seems that this will not be fixed in the swift project....

rizwan95 commented 2 years ago

Yeah, sorry for the brainfart. Removed it. Another passable solution would be

case windowScene(_: Any, windowLevel: UIWindow.Level)

and casting the associated value to UIWindowScene where needed (just one location in SwiftMessages.Config+Extensions.swift).

This does remove compile-time guarantee but requires no changes to applications and is the smallest change that could be made to fix it I believe. Dropping iOS 12 is certainly an option, but poses a problem for application developers where decisions regarding minimum targets are out of their hands.

Can we go with this solution? This seems to be optimal. @wtmoose

wtmoose commented 2 years ago

A quick fix using case windowScene(_: Any, windowLevel: UIWindow.Level) is on branch work/9.0.4 for folks to try.

Version 10 will revert back to case windowScene(_: UIWindowScene, windowLevel: UIWindow.Level) and instead require iOS 13.

acrabb commented 2 years ago

Any update on this?

mzhangFE commented 2 years ago

We tried the latest version and still saw the same issue. The quick fix mentioned by @wtmoose worked. I may have missed something here but why could you make that as the official fix? Also some apps still support iOS 12 so dropping iOS 12 is not desired.