<div dir="ltr">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><br></div><div>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><div class="gmail_quote">On Tue, Jul 19, 2016 at 9:52 PM, Tony Parker <span dir="ltr"><<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div style="direction:inherit">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="HOEnZb"><font color="#888888"><br>- Tony</font></span></div><div><div class="h5"><div><br>On Jul 19, 2016, at 6:32 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>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><br><div>-- </div><div>Brent Royal-Gordon</div>Sent from my iPhone</div><div><br>On Jul 19, 2016, at 4:33 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div>Hi John,<div><br></div><div>Thanks for filing the bug.</div><div><br></div><div>The root cause of the issue is that the importer would turn the following methods into the same name:</div><div><br></div><div><font face="Menlo">- (void)encodeInt:(int)x forKey:(NSString *)k;</font></div><div><font face="Menlo">- (void)encodeInt32:(uint32_t)x forKey:(NSString *)k;</font></div><div><br></div><div>Plus, there is the added confusion that this method:</div><div><br></div><div><font face="Menlo">- (void)encodeInteger:(NSInteger)x forKey:(NSString *)k;</font></div><div><br></div><div>is imported into Swift like this:</div><div><br></div><div><font face="Menlo">func encode(_ x: Int, forKey k : String)</font></div><div><br></div><div>where, as you can see, “Int” means “NSInteger”, but not the C “int”.</div><div><br></div><div>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><br></div><div><font face="Menlo">func encodeInt(_ x : Int32, forKey k : String)</font></div><div><font face="Menlo">func encodeInt32(_ x : Int32, forKey k : String)</font></div><div><font face="Menlo">func encodeInt64(_ x : Int64, forKey k : String)</font></div><div><font face="Menlo">func encodeInteger(_ x : Int, forKey k : String)</font></div><div><br></div><div>and so on, for all of the encode methods, so they are consistent.</div><div><br></div><div>- Tony</div><div><br><div><blockquote type="cite"><div>On Jul 19, 2016, at 8:20 AM, John Spurlock <<a href="mailto:john.spurlock@gmail.com" target="_blank">john.spurlock@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Ok, filed a new bug for the encodeInt:forKey issue: <a>rdar://problem/27425997</a><div><br></div><div>Ensured it reproduces in xcode beta 3, swift version 3.0 (swiftlang-800.0.34.6 clang-800.0.33)</div><div><br></div><div>Is there anything I can do in the meantime as a swift-only workaround to fix my custom NSCoder?</div><div><br></div><div>Thanks,</div><div>- john</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 10:52 PM, Tony Parker <span dir="ltr"><<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
<br>
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 <a href="http://bugreport.apple.com/" rel="noreferrer" target="_blank">bugreport.apple.com</a> and let me know the radar number, and we’ll look into it.<br>
<br>
Thanks,<br>
- Tony<br>
<div><div><br>
> On Jul 18, 2016, at 6:33 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br>
><br>
>> Hi Tony - when I add that attribute, I get an error at compile-time:<br>
>> Objective-C method has a different selector from the method it overrides ('encodeInt:forKey:' vs. 'encodeInteger:forKey:')<br>
>><br>
>> 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>
>><br>
>> Any other ideas? See the same thing over there? You should be able to paste that into a new swift 3 test.<br>
><br>
> 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>
><br>
> 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>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></blockquote></div></blockquote></div></div></div></blockquote></div><br></div>