[swift-users] Possible swift 3 method rewrite issue with NSRequestConcreteImplementation ?

Jordan Rose jordan_rose at apple.com
Thu Jul 21 17:46:22 CDT 2016 

OH. I completely misread this, and jumped to the mistake I would have made. You’re all correct. Sorry, Tony; sorry, John.

Jordan

> On Jul 21, 2016, at 15:06, John Spurlock <john.spurlock at gmail.com> wrote:
> 
> Nope, that doesn't work, try it yourself.
> 
> I tried that, any many more variations, before posting the minimal repro example here.
> 
> On Thu, Jul 21, 2016 at 5:46 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
> 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.
> 
> Jordan
> 
> 
>> On Jul 21, 2016, at 13:06, Tony Parker via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> FYI:
>> 
>> https://github.com/apple/swift/pull/3663 <https://github.com/apple/swift/pull/3663>
>> 
>> - Tony
>> 
>>> On Jul 20, 2016, at 12:10 PM, Tony Parker via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>>> 
>>>> On Jul 20, 2016, at 5:17 AM, John Spurlock <john.spurlock at gmail.com <mailto:john.spurlock at gmail.com>> wrote:
>>>> 
>>>> 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.
>>>> 
>>> 
>>> Agreed; I’m trying out a few approaches to see what works best.
>>> 
>>>> 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?
>>>> 
>>> 
>>> 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.
>>> 
>>> - Tony
>>> 
>>>> On Tue, Jul 19, 2016 at 9:52 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>>>> 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. 
>>>> 
>>>> - Tony
>>>> 
>>>> On Jul 19, 2016, at 6:32 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>>> 
>>>>> 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. 
>>>>> 
>>>>> -- 
>>>>> Brent Royal-Gordon
>>>>> Sent from my iPhone
>>>>> 
>>>>> On Jul 19, 2016, at 4:33 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>>>>> 
>>>>>> Hi John,
>>>>>> 
>>>>>> Thanks for filing the bug.
>>>>>> 
>>>>>> The root cause of the issue is that the importer would turn the following methods into the same name:
>>>>>> 
>>>>>> - (void)encodeInt:(int)x forKey:(NSString *)k;
>>>>>> - (void)encodeInt32:(uint32_t)x forKey:(NSString *)k;
>>>>>> 
>>>>>> Plus, there is the added confusion that this method:
>>>>>> 
>>>>>> - (void)encodeInteger:(NSInteger)x forKey:(NSString *)k;
>>>>>> 
>>>>>> is imported into Swift like this:
>>>>>> 
>>>>>> func encode(_ x: Int, forKey k : String)
>>>>>> 
>>>>>> where, as you can see, “Int” means “NSInteger”, but not the C “int”.
>>>>>> 
>>>>>> 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:
>>>>>> 
>>>>>> func encodeInt(_ x : Int32, forKey k : String)
>>>>>> func encodeInt32(_ x : Int32, forKey k : String)
>>>>>> func encodeInt64(_ x : Int64, forKey k : String)
>>>>>> func encodeInteger(_ x : Int, forKey k : String)
>>>>>> 
>>>>>> and so on, for all of the encode methods, so they are consistent.
>>>>>> 
>>>>>> - Tony
>>>>>> 
>>>>>>> On Jul 19, 2016, at 8:20 AM, John Spurlock <john.spurlock at gmail.com <mailto:john.spurlock at gmail.com>> wrote:
>>>>>>> 
>>>>>>> Ok, filed a new bug for the encodeInt:forKey issue:  rdar://problem/27425997 <>
>>>>>>> 
>>>>>>> Ensured it reproduces in xcode beta 3, swift version 3.0 (swiftlang-800.0.34.6 clang-800.0.33)
>>>>>>> 
>>>>>>> Is there anything I can do in the meantime as a swift-only workaround to fix my custom NSCoder?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> - john
>>>>>>> 
>>>>>>> On Mon, Jul 18, 2016 at 10:52 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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 bugreport.apple.com <http://bugreport.apple.com/> and let me know the radar number, and we’ll look into it.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> - Tony
>>>>>>> 
>>>>>>> > On Jul 18, 2016, at 6:33 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>>>>>> >
>>>>>>> >> Hi Tony - when I add that attribute, I get an error at compile-time:
>>>>>>> >> Objective-C method has a different selector from the method it overrides ('encodeInt:forKey:' vs. 'encodeInteger:forKey:')
>>>>>>> >>
>>>>>>> >> 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"
>>>>>>> >>
>>>>>>> >> Any other ideas?  See the same thing over there?  You should be able to paste that into a new swift 3 test.
>>>>>>> >
>>>>>>> > 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.
>>>>>>> >
>>>>>>> > 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.
>>>>>>> >
>>>>>>> > --
>>>>>>> > Brent Royal-Gordon
>>>>>>> > Architechies
>>>>>>> >
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160721/05e437c8/attachment.html>

More information about the swift-users mailing list