Following code worked fine in 1.1 and stops working at the reflection reflect(a) in 1.2
class AClass {
var some : String = "Hans"
var thing : Double
init( t: Double ) {
thing = t
}
}
class BClass : AClass {
}
var a = BClass(t: 1.1)
var mirror = reflect(a) // FAILS
for var index=0; index<mirror.count; ++index {
}
Though reflect(a).valueType would work and in addition give more meaningfull output/information than before.
Which leads me to two questions:
Does anybody know what changed with reflection? What could be wrong? Previously i could also iterate over the properties of the Object.
Where can i inspect such changes? I don`t find anything about reflection in the offical documentation and there are no notes about reflection changes on the blog or anywhere else, can i browse the source somehow? (never tried)
Update: XCode 6.3 Beta 2 Swift 1.2: It was a bug and now it works.
It turns out this is a (confirmed) bug in Swift 1.2
I will post more information when i have it.
Related
I'm trying to test debugQuickLookObject I'm using Xcode 12.4 but the sample code given doesn't return a String in the QuickLook Debugger or the console, is debugQuickLookObject still valid?
class User {
var name = "Duane Dibbley"
var age = 28
#objc func debugQuickLookObject() -> Any? {
return "My name is \(name) and I'm \(age)."
}
}
I've tried inheriting from NSObject - no joy, I can't even confirm if the method signature is correct :-s
Code from here: https://www.hackingwithswift.com/example-code/language/how-to-create-quick-look-debug-previews-for-your-custom-types
I managed to get the code working, but only for iOS based projects, code can be found here:
https://github.com/nthState/RealityKitDebugger
I wish I knew why macOS based projects don't work as expected.
I am not sure if it is a bug or it is really how things should work?
class A {
init() throws { }
}
class B {
lazy var instance = A()
}
this code compiles without mistakes using XCode 9 and latest Swift version, and works perfect unless Class A init() really throws, then lazy var is null pointer. But shouldn't be this code somehow not be compiled?
This is indeed a bug (SR-7862) – you cannot throw errors out of a property initialiser context (and even if you could, you would be required to prefix the call with try), therefore the compiler should produce an error.
I have opened a pull request to fix this (#17022).
Edit: The patch has now been cherry-picked to the 4.2 branch, so it'll be fixed for the release of Swift 4.2 with Xcode 10 (and until the release you can try a 4.2 snapshot).
As an answer to your question:
But shouldn't be this code somehow not be compiled?
Well, at some point your code snippet worked without any issue (because -as you mentioned- the class A init doesn't actually throws), so it could be compiled without any problem. To make it more clear, consider it as a similar case to the following one:
let myString: String? = nil
print(myString!) // crashes!
it will get compiled just fine! although we all know that it crashes when evaluating myString!, i,e we do know it causes a run-time crash, but that doesn't mean that the compiler should prevent it because it could be valid at some point (for instance if we declare it as let myString: String? = "Hello"); Similarly to your case, it could be valid at some point -as mentioned above-.
Usually, for such cases we -as developers- are the responsible to handle it based on what's the desired behavior(s).
Referring to this case, we might need to ask:
"How can we implement the instance lazy variable to catch an error (with a do-catch block)?"
Actually, this code won't compile:
class B {
lazy var instance:A = {
do {
let myA = try A()
return myA
} catch {
print(error)
}
}()
}
complaining that:
Missing return in a closure expected to return 'A'
because obviously reaching the catch block means that there is nothing to be returned. Also, as you mentioned even if you implemented it as
lazy var instance = A()
you will not get a compile-time error, however trying to use it with an actual throwing should leads to run time error:
let myB = B()
print(myB.instance) // crash!
What I would suggest for resolving this issue is to declare instance as lazy optional variable:
class B {
lazy var instance:A? = {
do {
let myA = try A()
return myA
} catch {
print(error)
}
return nil
}()
}
At this point, if we assume that A initializer always throws, trying to access it:
let myB = B()
print(myB.instance)
should log:
caught error
nil
without causing any crash. Otherwise, it should works fine, for instance:
let myB = B()
myB.instance?.doSomething() // works fine
I recently converted an Xcode project to Swift 4. I fixed all the syntax errors. However, my app now crashes, after outputting an error message which starts
Class MPExportableArtworkProperties is implemented in both...
I have been looking around S/O but all I find is that its related to MapBox which I don't even have in my project/podfile. Can it have something to do with the regular map-kit? It crashes the app when I open the tab with my map, so I'm guessing that's where the problem is.
Full error message, formatted for readability:
objc[24634]: Class MPExportableArtworkProperties is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/MediaPlaybackCore.framework/MediaPlaybackCore
(0x126b1b108) and
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/MediaPlayer.framework/MediaPlayer
(0x1258107d0).
One of the two will be used. Which one is undefined.
This is the plowerthingscontroller saying that you are logged in
libc++abi.dylib: terminating with uncaught exception of type
NSException
I had this exact error, and in the end found it was due to something completely different: a circular dependency. Consider:
class DependencyManager {
static let shared = DependencyManager()
let aDependency: SomeDependency
init() {
aDependency = SomeDependency()
}
func resolve() -> SomeProtocol {
// Create the actual class
return 0
}
}
where SomeDependency requires SomeProtocol
class SomeDependency {
let x: SomeProtocol
// Me trying to be clever and auto-inject the dependency
init(x: SomeProtocol = DependencyManager.shared.resolve()) {
self.x = x
}
}
So when you first access DependencyManager.shared it tries instantiate SomeDependency, which requires DependencyManager.shared to already be instantiated.
I have no idea why MPExportableArtworkProperties is mentioned in the error, however cleaning up the code fixed the issue for me.
I am trying to figure out why I am having constant compile problems with this type of construct in Xcode 6.3.2.
class Foo {
static let CONSTANT_NAME = "CONSTANT_STRING"
...
func bar () -> String {
var s = String(format:"%s,%d\n", CONSTANT_NAME, 7)
return s
}
...
}
As I understand the language, this should be perfectly legal code however Xcode is constantly (hah-pun) having issues with it raising the error
"there is no member CONSTANT_NAME in class Foo"
If I get lucky and force it to clean, and then rebuild it will some times sort itself out and work. Other times, even doing that, then trying an open/close project will still not resolve the issue.
So, I guess my implicit follow up question (if the answer to the above is - it is legal code) is: is the Xcode Swift compiler that buggy that even basic things like this are likely to cause problems? If so, swift seems to be in a pretty bad state.
static is class property, that means you have to call it like this ClassName.property
class Foo {
static let CONSTANT_NAME = "CONSTANT_STRING"
func bar () -> String {
var s = String(format:"%s,%d\n", Foo.CONSTANT_NAME, 7)
return s
}
}
That is not a bug. That is what it should be. A class property "belongs" to the class.
If you want your code work without using ClassName, do not use static
class Foo {
let CONSTANT_NAME = "CONSTANT_STRING"
func bar () -> String {
var s = String(format:"%s,%d\n",CONSTANT_NAME, 7)
return s
}
}
More details in the Apple Documentation
The static let syntax is legal and valid. The issue is that you must fully qualify that variable when you access it:
var s = String(format:"%s,%d\n", Foo.CONSTANT_NAME, 7)
The compiler error is a bit obtuse, but it is telling the truth... CONSTANT_NAME is not a member, but a type property of class Foo: Swift Type Properties
I hear you about saving key strokes. I've personally been trying to make my Swift code as idiomatic as possible by milking every short cuts but when you find code like this, you should be glad that the compiler asks you to keep on the safe side:
class Foo {
static let CONSTANT = "hello"
func bar() -> String {
let CONSTANT = "bye"
return CONSTANT // I know which one! Thanks Swift!
}
}
println(Foo.CONSTANT)
println(Foo().bar())
If I enter the following code in a REPL or Playground or main project, it just hangs when it attempts to create the empty list.
import Cocoa
public final class Box<T> {
private let _value : () -> T
public init(_ value : T) {
self._value = { value }
}
public var value: T {
return _value()
}
}
public enum List<U> {
case Empty
case Cons(U, Box<List<U>>)
}
var l = List<Int>.Empty;
I know this is a popular technique used to get around the fact that Swift doesn't let enums be truly recursive without some indirection (served by the Box class in this example).
I mean it's done here in this project, so I assume this works for some people.
I uninstalled and reinstalled XCode thinking somehow I had some "bad bits" left over from previous beta versions. Anyone else have this issue?
UPDATE 11/17/2015: Of course this question and answer are now obsolete. Please see how to define Recursive Enumerations here: Swift Programming Language - Enumerations
Was working with someone on this and they resolved it.
https://github.com/typelift/swiftz/issues/114
https://github.com/typelift/swiftz/pull/120
The answer is to box the first parameter of Cons as well (you can use an autoclosure) like this Cons(#autoclosure () -> U, Box<List<U>>) and that will fix it. A rdar was filed.