Thanks for your explanation. I still think the compiler should not be that smart, causing only itself could understanding what is going on. It will be a nightmare.
Owen On Tue, Apr 19, 2016 at 7:09 PM, Marco Feltmann via swift-users < swift-users@swift.org> wrote: > Just guessed since I try to separate Swift from Objective-C frameworks. > > Am 19.04.2016 um 03:15 schrieb zh ao: > >> I don't think NSNumber is OK here. As t1 is a struct not a literal value. >> > In fact t1 in an OPTIONAL struct. > That means it can point to anything from `nil` to Int Struct, NSInteger > and NSNumber. > AFAIR it automatically bridges to NSNumber as soon as you import > Foundation or a similiar framework. Same works with String. String is a > struct used in plain Swift and NSString used with Foundation. > >> If NSNumber is OK. I think the compiler is too smart than it should be. >> > Indeed it is. Way to smart. > It is that smart that it sometimes stands in its own way. > At least when used with Objective-C. Your question outlines one of those > strange side effects. > >> Also, you should aware that right side of let y works in print(), but does >> not work in let, which is not consistent somehow. >> > It is consistent. > You can map an OPTIONAL integer to NSNumber (using Foundation framework) > but you cannot map an OPTIONAL integer to NSString. > > "But wait a sec, how can NSFount(name: "", size: 0) result in an > NSNumber?" you may ask. > I don't now. > The behaviour of NSFonts +fonttWithName:size: for empty/not found font > name is not defined in the documentation, so ANY result is correct. > > _______________________________________________ > 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
