Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift: When Unused Code Is a Bug

peripheryapp.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Swift: When Unused Code Is a Bug

#71

Post by wool_gather »

arcticbull wrote: post #55
wool_gather wrote: post #53

Earlier quoted context omitted.

I guess fundamentally, this is the question I have about this situation: would you ever, in real code, want dispatch to go straight back to the default implementation when you have in hand a value with a custom implementation? I may be having a failure of imagination; but I certainly haven't ever seen a case where I'd want that.

I’d imagine the issue lies in Swift classes utilizing only static dispatch. The protocol conformance creates a witness table populated by the methods of the class in question, but as Swift classes have no vtables except in ObjC compatability mode (right?) there’s no way to pass down the invocation from the protocol witness to a specific subclass as the method can not be resolved at runtime. This is the difference bet…

Classes do get dynamic dispatch at least for methods/properties that can be overridden (i.e., `open`). I believe the value must also still have a reference to its class's method impls -- otherwise what happens when you cast it `if let noReallyLazyGreeter = lazyGreeter as? LazyGreeter {`? Not certain about these details, though.

Re: Swift: When Unused Code Is a Bug

#72

Post by sharp11 »

delinka wrote: post #70
sharp11 wrote: post #64

Earlier quoted context omitted.

I’m curious to know why... Looks like typical mixin pattern, no?

An interface declaration is not the right place for implementation. If you want a default implementation, use a base class and inherit, overriding if you don't want the default. This bug is now another good reason not to use default implementations on interfaces.

Ok, thanks. Sounds like you are not a fan of mixins! :)

Re: Swift: When Unused Code Is a Bug

#73

Post by torpidor »

mpweiher wrote: post #68
torpidor wrote: post #59

Earlier quoted context omitted.

> That means that greeter and greeter1 are just two references to the exact same underlying object They are two references that differ in type . It is a feature in Swift (and any strongly-typed language) that references are typed and when types differ, behaviors can differ. I understand you disagree with this design principle but it is an inherent property of strong type systems that have reference semantics. > two d…

> There isn’t any such thing as a “value type instance” Hmm.. "An instance of a class is traditionally known as an object. However, Swift structures and classes are much closer in functionality than in other languages, and much of this chapter describes functionality that applies to instances of either a class or a structure type. Because of this, the more general term instance is used." and "Structure and Class Inst…

> You are confusing the type of the variable with the type of the object/value contained in the variable.

I’m not “confusing” them; I’m prioritizing the former over the latter, whereas you are prioritizing the latter over the former. This is the classic strong/weak typing debate.

If you want a language in which the dynamic type overrides the static type, there are several (including Swift if you are explicit about the override, and sometimes even if you are not explicit).

> A static type system is there to ensure that the type of the variable matches the type in its contents

A strong type system is there to apply strict type rules. one of Swift’s type rules is that Greeter.greet() calls that function or an override, not an unrelated function that could only be inferred at runtime.

Re: Swift: When Unused Code Is a Bug

#74

Post by mmfl »

If the concept is that protocol requirements represent the "customisation points" of a protocol, shouldn't this apply equally to conforming classes and subclasses with inherited conformance? So I would be in favour of fixing this. Conversely, perhaps protocol extension methods etc not declared as protocol requirements could e.g. elicit a compiler warning when "overridden" by conforming classes/subclasses with inherited conformance (since they are not intended as customisation points)? I think these changes would aid reasoning about protocols and reduce bugs.

Re: Swift: When Unused Code Is a Bug

#75

Post by [deleted] »

torpidor wrote: post #73
mpweiher wrote: post #68

Earlier quoted context omitted.

> There isn’t any such thing as a “value type instance” Hmm.. "An instance of a class is traditionally known as an object. However, Swift structures and classes are much closer in functionality than in other languages, and much of this chapter describes functionality that applies to instances of either a class or a structure type. Because of this, the more general term instance is used." and "Structure and Class Inst…

> You are confusing the type of the variable with the type of the object/value contained in the variable. I’m not “confusing” them; I’m prioritizing the former over the latter, whereas you are prioritizing the latter over the former. This is the classic strong/weak typing debate. If you want a language in which the dynamic type overrides the static type, there are several (including Swift if you are explicit about th…

[deleted]

Re: Swift: When Unused Code Is a Bug

#76

Post by slavapestov »

joeblau wrote: post #13
anon180719 wrote: post #12

Earlier quoted context omitted.

Oh, that's definitely weird then. Is there an RFC to have that fixed in some way?

I don't think there is. I think the code is functioning as expected — it's just written in a super confusing way. What should probably happen is that the compiler should throw an error about redefining a function in a super classes extension. I'm not a compiler engineer but a check for that seems like it would be intensive unless that information is codified in the AST somehow.

It's a bug - https://bugs.swift.org/browse/SR-103

Re: Swift: When Unused Code Is a Bug

#77

Post by jolux »

delinka wrote: post #70
sharp11 wrote: post #64

Earlier quoted context omitted.

I’m curious to know why... Looks like typical mixin pattern, no?

An interface declaration is not the right place for implementation. If you want a default implementation, use a base class and inherit, overriding if you don't want the default. This bug is now another good reason not to use default implementations on interfaces.

Protocol extensions are extremely powerful and safe if used correctly and not mixed with class inheritance as in this example.
Post reply on HN