@encode() is broken for CLLocationCoordinate2D

Originator:joemuers.developer
Number:rdar://19766176 Date Originated:09/02/2015
Status:? Resolved:No
Product:iOS Product Version:
Classification: Reproducible:Always
 
Summary:
@encode is supposed to provide a description of a given data type. However it does not work for CLLocationCoordinate2D, instead of returning "{CLLocationCoordinate2D =dd}" (which is what it should be), it returns "{??=dd}". 
This actually happens with *ANY* struct which has been defined anonymously with a typedef.  Hence, for:
typedef struct MyStruct {
    double aDouble;
    double anotherDouble;
} MyStruct;
@encode(MyStruct) will work correctly, returning "{MyStruct=dd}".
But this (note the missing first "MyStruct" in the definition):
typedef struct {
    double aDouble;
    double anotherDouble;
} MyStruct;
will NOT work, and returns "{??=dd}".
CLLocationCoordinate2D (in <CoreLocation/CLLocation.h>) is defined in this way, and so it does not work.
***Note that an "#import <CoreLocation/CLLocation.h>" in the relevant header file does NOT fix the problem.***

Steps to Reproduce:
In an active Xcode debugger window, type:
po @encode(CLLocationCoordinate2D)

Expected Results:
"{CLLocationCoordinate2D=dd}"

Actual Results:
"{??=dd}"

Version:
Any

Notes:
Two possible fixes, for CLLocationCoordinate2D, correct the definition of it to:
typedef struct CLLocationCoordinate2D {
	CLLocationDegrees latitude;
	CLLocationDegrees longitude;
} CLLocationCoordinate2D;
(Note the extra CLLocationCoordinate2D in the definition).

OR (better) fix the implementation of @encode so that it is clever enough to look for typedef's with anonymous structs in the general case.

Configuration:
Any configuration, the problem is with the implementation of the @encode objective-C compiler directive.

Comments

I responded to Apple on 05/03/2015

I'm sorry but this is not "intended behaviour" - if you don't want to change the behaviour of @encode, then you should fix the implementation of CLLocationCoordinate2D so that it also has a tag name which is the same as it's typedef name. Because of this problem, CLLocationCoordinate2D breaks when you try to use NSKeyedArchiver. I can workaround the issue by manually wrapping up the values manually, but I shouldn't have to. Somebody else came across the same problem here: http://stackoverflow.com/questions/12291279/nskeyedarchiver-fails-with-cllocationcoordinate2d-structs-why

By joemuers.developer at Dec. 5, 2018, 5:42 p.m. (reply...)

Apple responded on 05/03/2015

Engineering has determined that this issue behaves as intended based on the following information: symbol before '=' is the tag name and not the typedef name (which happen to be the same in your test). And '?' encodes that there is no tag name. In other words, encoding should be identical to: @encode(struct { double aDouble; double anotherDouble; }); Any change to encoding to include typedef name will break ABI compatibility. If you have questions regarding this resolution, please update your bug report with that information. We are now closing this bug report. Please be sure to regularly check new Apple releases for any updates that might affect this issue.

By joemuers.developer at Dec. 5, 2018, 5:42 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!