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.
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.
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.
On Jul 19, 2016, at 6:32 PM, Brent Royal-Gordon <email@example.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.
Sent from my iPhone
On Jul 19, 2016, at 4:33 PM, Tony Parker <firstname.lastname@example.org> >> wrote:
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.
On Jul 19, 2016, at 8:20 AM, John Spurlock <email@example.com> >> wrote:
Ok, filed a new bug for the encodeInt:forKey issue:
Ensured it reproduces in xcode beta 3, swift version 3.0
Is there anything I can do in the meantime as a swift-only workaround to
fix my custom NSCoder?
On Mon, Jul 18, 2016 at 10:52 PM, Tony Parker <firstname.lastname@example.org> >> 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
> On Jul 18, 2016, at 6:33 PM, Brent Royal-Gordon < >>> email@example.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