<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">OH. I completely misread this, and jumped to the mistake I would have made. You’re all correct. Sorry, Tony; sorry, John.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 21, 2016, at 15:06, John Spurlock <<a href="mailto:john.spurlock@gmail.com" class="">john.spurlock@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Nope, that doesn't work, try it yourself.<div class=""><br class=""></div><div class="">I tried that, any many more variations, before posting the minimal repro example here.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jul 21, 2016 at 5:46 PM, Jordan Rose <span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I’m a bit late here, but I don’t see why this is necessary. John overrode 'encode(_: Int, forKey: String)’ instead of ‘encode(_: Int32, forKey: String)’. Sure, overloading makes this kind of mistake harder to spot, especially when the run-time error comes from Objective-C, but it’s hardly unusual for a Swifty program.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jordan</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 21, 2016, at 13:06, Tony Parker via swift-users <<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">FYI:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift/pull/3663" target="_blank" class="">https://github.com/apple/swift/pull/3663</a></div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 20, 2016, at 12:10 PM, Tony Parker via swift-users <<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" class=""><div class=""><br class="">On Jul 20, 2016, at 5:17 AM, John Spurlock <<a href="mailto:john.spurlock@gmail.com" target="_blank" class="">john.spurlock@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">1. Since encoding/decoding various types is the principal domain of this type, it seems ok to be overly clear in the method names here.<div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Agreed; I’m trying out a few approaches to see what works best.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2. Is there a way to systematically look for other types that may also have this problem lurking with ints or other similar overload groups?</div></div><div class="gmail_extra"><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t think so. I also know that the importer will happily create ambiguous method names, for example when importing two ObjC methods that are the same except that one has an options argument. The options gets a default value and presto - two methods with the same signature. We only find out when someone tries to use it in other source code.</div><div class=""><br class=""></div><div class="">- Tony</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 19, 2016 at 9:52 PM, Tony Parker<span class=""> </span><span dir="ltr" class=""><<a href="mailto:anthony.parker@apple.com" target="_blank" class="">anthony.parker@apple.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto" class=""><div class=""><div style="direction:inherit" class="">I thought of the exact same name, but I'm not enthusiastic about the inconsistency this creates with all of the other decode methods on NSCoder. I'm discussing with a few people to decide what to do next. </div><span class=""><font color="#888888" class=""><br class="">- Tony</font></span></div><div class=""><div class=""><div class=""><br class="">On Jul 19, 2016, at 6:32 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">You could just do the one and call it encodeCInt. I think people would understand that it's different because it's using a sort-of-foreign type. <br class=""><br class=""><div class="">-- </div><div class="">Brent Royal-Gordon</div>Sent from my iPhone</div><div class=""><br class="">On Jul 19, 2016, at 4:33 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" target="_blank" class="">anthony.parker@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Hi John,<div class=""><br class=""></div><div class="">Thanks for filing the bug.</div><div class=""><br class=""></div><div class="">The root cause of the issue is that the importer would turn the following methods into the same name:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">- (void)encodeInt:(int)x forKey:(NSString *)k;</font></div><div class=""><font face="Menlo" class="">- (void)encodeInt32:(uint32_t)x forKey:(NSString *)k;</font></div><div class=""><br class=""></div><div class="">Plus, there is the added confusion that this method:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">- (void)encodeInteger:(NSInteger)x forKey:(NSString *)k;</font></div><div class=""><br class=""></div><div class="">is imported into Swift like this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func encode(_ x: Int, forKey k : String)</font></div><div class=""><br class=""></div><div class="">where, as you can see, “Int” means “NSInteger”, but not the C “int”.</div><div class=""><br class=""></div><div class="">I’m not really sure how to resolve this and still allow for subclassing without simply reverting these names back to Swift 2.2 style, so I think that’s probably what I’ll have to do:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func encodeInt(_ x : Int32, forKey k : String)</font></div><div class=""><font face="Menlo" class="">func encodeInt32(_ x : Int32, forKey k : String)</font></div><div class=""><font face="Menlo" class="">func encodeInt64(_ x : Int64, forKey k : String)</font></div><div class=""><font face="Menlo" class="">func encodeInteger(_ x : Int, forKey k : String)</font></div><div class=""><br class=""></div><div class="">and so on, for all of the encode methods, so they are consistent.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 19, 2016, at 8:20 AM, John Spurlock <<a href="mailto:john.spurlock@gmail.com" target="_blank" class="">john.spurlock@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Ok, filed a new bug for the encodeInt:forKey issue: <a class="">rdar://problem/27425997</a><div class=""><br class=""></div><div class="">Ensured it reproduces in xcode beta 3, swift version 3.0 (swiftlang-800.0.34.6 clang-800.0.33)</div><div class=""><br class=""></div><div class="">Is there anything I can do in the meantime as a swift-only workaround to fix my custom NSCoder?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- john</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jul 18, 2016 at 10:52 PM, Tony Parker<span class=""> </span><span dir="ltr" class=""><<a href="mailto:anthony.parker@apple.com" target="_blank" class="">anthony.parker@apple.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We renamed some of these methods for Swift 3 in an attempt to remove some of the confusion surrounding which of these did what - they were really named for C types and not Swift ones.<br class=""><br class="">encodeInt:forKey: and decodeInt:forKey: are the two missing ones, since they were easily confused with the Swift Int type. I think we’ll have to figure out a different approach here. John, please file a bug at<span class=""> </span><a href="http://bugreport.apple.com/" rel="noreferrer" target="_blank" class="">bugreport.apple.com</a><span class=""> </span>and let me know the radar number, and we’ll look into it.<br class=""><br class="">Thanks,<br class="">- Tony<br class=""><div class=""><div class=""><br class="">> On Jul 18, 2016, at 6:33 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>> wrote:<br class="">><br class="">>> Hi Tony - when I add that attribute, I get an error at compile-time:<br class="">>> Objective-C method has a different selector from the method it overrides ('encodeInt:forKey:' vs. 'encodeInteger:forKey:')<br class="">>><br class="">>> If I update to encodeInteger:forKey as the fix describes, it compiles, but I'm getting the same original problem at runtime. i.e. "encodeInt:forKey: only defined for abstract class"<br class="">>><br class="">>> Any other ideas? See the same thing over there? You should be able to paste that into a new swift 3 test.<br class="">><br class="">> If you look at the NSCoder documentation, you'll see 25 methods in the Swift version of the "Encoding General Data" section, and 27 (non-deprecated) in the Objective-C version. `-encodeInt:forKey:` has no Swift equivalent. I'm not sure what the other missing method is.<br class="">><br class="">> I think this is probably a bug or design oversight, and I'd recommend you file a radar against Foundation. If this is a primitive method for NSCoding, it needs to be accessible from Swift.<br class="">><br class="">> --<br class="">> Brent Royal-Gordon<br class="">> Architechies<br class="">><br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div></blockquote></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-users mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:swift-users@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-users@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-users</a></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>