Swift 4.2 source compatibility

Alejandro_Martinez · June 14, 2018, 2:19pm

Hi,
I just opened my project with Xcode 10 and I can see a bunch of compiler errors.
I'm happy doing the changes to support Swift 4.2, but I just wondered if it's worth to raise JIRA tickets for it.

One of the issues I see is an exposed "id" from Objective-C can't be casted with "as" to NSString anymore.

Is this a expected breaking change or should I raise a issue for it?
And in the more general case, is there an easy way to know what are expected source breaking changes?

jrose · June 14, 2018, 3:54pm

id could never be converted to NSString with as, so something else must be going on. If you can provide your project, please do file a bug report!

Alejandro_Martinez · June 14, 2018, 4:01pm

Interesting!

That "label.text" that you see in the screenshoot comes from TTTAttributedLabel that redefines the UILabel property.

github.com

TTTAttributedLabel/TTTAttributedLabel/blob/master/TTTAttributedLabel/TTTAttributedLabel.h#L77


      
          
          
/**
           The background corner radius. Value must be an `NSNumber`. Default value is `5.0f`.
           */
          extern NSString * const kTTTBackgroundCornerRadiusAttributeName;
          
          
@protocol TTTAttributedLabelDelegate;
          
          
// Override UILabel @property to accept both NSString and NSAttributedString
          @protocol TTTAttributedLabel <NSObject>
          @property (nonatomic, copy) IBInspectable id text;
          @end
          
          
IB_DESIGNABLE
          
          
/**
           `TTTAttributedLabel` is a drop-in replacement for `UILabel` that supports `NSAttributedString`, as well as automatically-detected and manually-added links to URLs, addresses, phone numbers, and dates.
           
           ## Differences Between `TTTAttributedLabel` and `UILabel`
           
           For the most part, `TTTAttributedLabel` behaves just like `UILabel`. The following are notable exceptions, in which `TTTAttributedLabel` may act differently:

My project is quite large and from a private company, but I can try if it happens in a sample project with that library.

jrose · June 14, 2018, 4:04pm

Ah, this is a known change: previously if there were multiple properties with the same name, one would get picked pretty much at random. Now the compiler tries to choose properly (though it seems to be failing, since you provided type context with ! and as String). Please do file a bug if you can reproduce it!

Alejandro_Martinez · June 14, 2018, 5:46pm

I created a sample project with the issue. Is attached in [SR-7997] Source compatibility (4.1 -> 4.2) when multiple properties have the same name · Issue #50530 · apple/swift · GitHub
I hope it helps ^^
Thanks!