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.par...@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.spurl...@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.par...@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 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 <br...@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
