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_r...@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@swift.org> wrote: > > FYI: > > https://github.com/apple/swift/pull/3663 > > - Tony > > On Jul 20, 2016, at 12:10 PM, Tony Parker via swift-users < > swift-users@swift.org> wrote: > > > On Jul 20, 2016, at 5:17 AM, John Spurlock <john.spurl...@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.par...@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 <br...@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.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 > > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users