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.spurl...@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_r...@apple.com > <mailto: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 <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>> wrote: >>> >>>> >>>> On Jul 20, 2016, at 5:17 AM, John Spurlock <john.spurl...@gmail.com >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>> <mailto: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 <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 >>>>>>> > <br...@architechies.com <mailto: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 <mailto:swift-users@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-users >>> <https://lists.swift.org/mailman/listinfo/swift-users> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users >> <https://lists.swift.org/mailman/listinfo/swift-users> > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
