Let color: UIColor = .clear gives Cannot access non-static member "clear" on type "UIColor!"

(wdb) #1

IDE: Fire
Version: Elements Version
Target (If relevant): Android/Java/iOS/OSX/Island(Platform)/Net/Net Core
If I am trying to use the common used Swift code:
let color: UIColor = .clear I am getting the following compiler error: Cannot access non-static member "clear" on type "UIColor!"

I assume this because in actual Objective-C it’s being defined as clearColor but would awesome if the common .clear works.

Expected Behavior:
Able to compile code using .clear (and other color definitions)
Actual Behavior:
Getting an compiler error saying the clear member is missing


  1. Create simple project
  2. Add the code let color: UIColor = .clear
  3. Notice compiler error
(marc hoffman) #2

From the error message, it seems that UIColor.clear is not static, not that I has the wrong name?

(wdb) #3

It’s a class var: https://developer.apple.com/documentation/uikit/uicolor/1621945-clear

(marc hoffman) #4

Yeah, you’re right. it looks like we don’t rename those, and the actual name is +[UIColor clearColor].

(wdb) #5

Yeah, that looks like it! I am wondering how Apple does this? Do they define some metadata in Objective-C’s bridge headers?

(marc hoffman) #6

Ha, I wish! that’d be sane!

no. they have hardcoded rules inside the Swift compiler to mangle the nice Cocoa names. Problem is their spec that that is inconsistent and does not always line up with what the actual compiler does.

We do the same remapping on import (for us, it is meta data in the .fx, and you can actually use the old or the new names). But this one seems to be one of the cases where we dont rename something they do.

Apple is really making a huge mess out of the elegance that used to be Cocoa, with Swift. it is a god-damn shame. I dread the day the/new actual OS APIs will be Swift-based, and not just mangled for use by Swift, because that’s the day developing for Mac and iOS will cease to be a joy :(.

1 Like
(wdb) #7


1 Like