search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.61k stars 10.37k forks source link

[SR-1478] Trouble calling NSLog #44087

Open mattneub opened 8 years ago

mattneub commented 8 years ago
Previous ID SR-1478
Radar None
Original Reporter @mattneub
Type Bug
Environment Toolchain: Swift Development Snapshot 2016-05-09 (a)
Additional Detail from JIRA | | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug, ClangImporter | |Assignee | None | |Priority | Medium | md5: a9195db12f010ffdde85171d9d0433a2

Issue Description:

This line now fails compilation:

NSLog("%@", self.childViewControllers)

The error message reads: 'NSLog' is unavailable: Variadic function is unavailable

However, that's probably just diagnostic; I can work around the problem by writing this:

NSLog("%@", self.childViewControllers as NSObject)

I can't quite tell whether this is a bug or whether it's deliberate, as I'm aware that automatic bridging has been tightened. However, I suspect that it is a bug, because this compiles:

NSLog("%@ %@ %@", segue.identifier! as NSObject, segue.sourceViewController, segue.destinationViewController)

If the problem were really that I am supposed to cast explicitly, I would expect to have to cast all three arguments explicitly, but I don't have to. It seems more likely that the compiler is confused.

belkadan commented 8 years ago

A Swift Array isn't a class instance, so it can't be directly printed with "%@". Auto-coercing to NSArray would be wrong because not all Arrays are Objective-C-compatible. So I think it's correct that you have to be explicit here.

That said, maybe we can do something about the error. Since we know there's a Swift version of NSLog, we'd do better not to even let the original C one show up.

mattneub commented 8 years ago

Maybe we should close this? The problem has gone away since we cut back on requiring everything to be explicitly cast from Swift type to bridged Objective-C type.

belkadan commented 8 years ago

I think that's still up in the air, but you could still get the same unexpected diagnostic if you passed a pure Swift struct type. (Of course you wouldn't be able to get it to work, but the diagnostic shouldn't say it's unavailable.)