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