Swift: When Unused Code Is a Bug

Post by Black-Plaid » Sun, Aug 05, 2018, 8:02 PM UTC

torpidor wrote: post #40

mpweiher wrote: post #19

Wow, Heisen-Swift, where the Heisenbugs are in the language specification! What an object is, which is roughly equivalent to its observed behavior, should never depend on how it is declared. let greeter = LazyGreeter() let greeter1: Greeter = greeter print(greeter) print(greeter1) greeter.greet() greeter1.greet() UPDATE: just in case it's not clear, this prints the following: greeter.LazyGreeter greeter.LazyGreeter s…

> What an object is, which is roughly equivalent to its observed behavior, should never depend on how it is declared. This is actually a statement that strong typing should not exist. A "declaration" (really a type declaration) indicates the type, and if observed behavior cannot depend on the types there is not much point to types. Or stated positively: in a strongly typed language, the types are part of 'what an obj…

Post by wool_gather » Sun, Aug 05, 2018, 8:24 PM UTC

wux wrote: post #35

This is an interesting demonstration of a hard edge of the language. It's not because Swift holds some sort of grudge against dynamic dispatch, but rather because it's trying to reconcile some subtly incompatible design goals: 1. Adding a default implementation for a protocol requirement shouldn't stop existing types that correctly conform to that protocol from compiling. This is a reasonable user expectation and mak…

    protocol P {
        func f()
    }

    class C : P {}    // Error!

    protocol P {
        func f()
    }
    extension P {
        func f() {}
    }

    class C : P {}    // Okay

    // This all compiles without any warnings?!
    protocol P {
        var i: Int { get set }
    }

    protocol Q : P {
        var i: Int { get }
    }

    class C : Q, P {
        var i = 10
    }

    // Now make a protocol that inherits from another,
    // where both are class/AnyObject constrained
    
    //---

    struct S : Hashable {    // Swift 4.1, synthesized 
        let s: String
    }
    extension S : Equatable {
        static func == (lhs: S, rhs: S) -> Bool {
            // Hashable semantics, smashable semantics. Hold my beer.
            return lhs.s.first == rhs.s.first
        }
    }

Post by syrrim » Sun, Aug 05, 2018, 8:50 PM UTC

didibus wrote: post #42

I don't know that you can really call this a bug? It just seems to be the design choice. Though I agree, it seems odd at first, and appears possibly accidental, it could have been on purpose. My question to swifters: what if LazyGreeter had another method, say lazyGreet, and you typed it as Greeter? Then you called let greeter : Greeter = LazyGreeter(); greeter.lazyGreet(); Would you expect this to work or fail? I'd…

Post by Dylan16807 » Sun, Aug 05, 2018, 9:01 PM UTC

ljm wrote: post #37

I'm reading the comments here about how the languages fails, or what it should have done better, but at the same time I'm feeling the same as I do when building up something with Kubernetes and the problem isn't really the language, it's the shortcuts we take with it to stay concise. e.g. in Kubernetes you can give a Pod, Deployment, Service, Ingress, Volume, etc. etc. the exact same name and in fact many examples en…

Post by wool_gather » Sun, Aug 05, 2018, 9:11 PM UTC

torpidor wrote: post #40

mpweiher wrote: post #19

Wow, Heisen-Swift, where the Heisenbugs are in the language specification! What an object is, which is roughly equivalent to its observed behavior, should never depend on how it is declared. let greeter = LazyGreeter() let greeter1: Greeter = greeter print(greeter) print(greeter1) greeter.greet() greeter1.greet() UPDATE: just in case it's not clear, this prints the following: greeter.LazyGreeter greeter.LazyGreeter s…

> What an object is, which is roughly equivalent to its observed behavior, should never depend on how it is declared. This is actually a statement that strong typing should not exist. A "declaration" (really a type declaration) indicates the type, and if observed behavior cannot depend on the types there is not much point to types. Or stated positively: in a strongly typed language, the types are part of 'what an obj…