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

61–70 of 77 posts

Re: Swift: When Unused Code Is a Bug

#61

Post by nangtrongvuon »

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…

I’m just a wee lad still dabbling in Swift, but I would say this would work, since the lazyGreet method is separate from the Greeter protocol.

Re: Swift: When Unused Code Is a Bug

#62

Post by delinka »

Providing a protocol with a default concrete implementation of the interface? That's not passing code review here.

Would I have caught the bug? Probably not. But it looks like bad form to me to provide that default implementation to Greeter, so please rewrite your code.

Re: Swift: When Unused Code Is a Bug

#63

Post by Buge »

It's good that Periphery catches the unused code.

But if that's the only reason it catches the problem, I think it could have room for improvement. For example in one place the error could exist, but at a different place, the real function could be called because the variable is declared as a LazyGreeter. Then Periphery wouldn't catch the problem.

One way to fully catch it would be to give a warning if a base class implements a protocol but a derived class doesn't. I'm not sure how many false positives this would have. Possibly you might only do this if the derived class tries to override a function from the base class's protocol.

Re: Swift: When Unused Code Is a Bug

#64

Post by sharp11 »

delinka wrote: post #62

Providing a protocol with a default concrete implementation of the interface? That's not passing code review here. Would I have caught the bug ? Probably not. But it looks like bad form to me to provide that default implementation to Greeter, so please rewrite your code.

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

Re: Swift: When Unused Code Is a Bug

#66

Post by scarface74 »

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…

I’m trying to wrap my C# brain around this...

Is this similar to the C# construct....

interface IGreeter { void Greet()}

class BaseGreeter :IGreeter {

public void Greet {Console.WriteLine(“Hello World”)}

public void IGreeter:Greet {Console.Writeline(“sup”)} }

}

Greeter greet1 = new Greeter();

IGreeter greet2 = greet1();

Console.Writeline(greet1 == greet2) greet1.Greet() greet2.Greet()

Would print I believe.

true

Hello World

sup

Re: Swift: When Unused Code Is a Bug

#67

Post by HNLogInShit »

sharp11 wrote: post #64
delinka wrote: post #62

Providing a protocol with a default concrete implementation of the interface? That's not passing code review here. Would I have caught the bug ? Probably not. But it looks like bad form to me to provide that default implementation to Greeter, so please rewrite your code.

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

mix-in

Re: Swift: When Unused Code Is a Bug

#68

Post by mpweiher »

torpidor wrote: post #59
mpweiher wrote: post #52

Earlier quoted context omitted.

> This is actually a statement that strong typing should not exist. Nope. It is a statement that objects shouldn't be different depending on how you look at them. The example is a class, so a reference type. That means that greeter and greeter1 are just two references to the exact same underlying object. Your example are two distinct value type instances that you happened to initialize from the same literal. So not e…

> 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 Instances"

..

"Structures and Enumerations Are Value Types

A value type is a type whose value is copied when it’s assigned to a variable or constant, or when it’s passed to a function.

You’ve actually been using value types extensively throughout the previous chapters. In fact, all of the basic types in Swift—integers, floating-point numbers, Booleans, strings, arrays and dictionaries—are value types, and are implemented as structures behind the scenes."

https://docs.swift.org/swift-book/LanguageGuide/ClassesAndSt...

> “references shouldn’t be different depending on their type.”

You are confusing the type of the variable with the type of the object/value contained in the variable. A static type system is there to ensure that the type of the variable matches the type its contents.

Re: Swift: When Unused Code Is a Bug

#69

Post by GRiMe2D »

a_t48 wrote: post #65

How much different is this from slicing in C++? IE: #include using namespace std; struct Greeter { void greet() { cout

In C++ world this is expected behavior AND it's documented. But in swift, protocols cannot declare default implementations but it's possible to define implementation to protocol using extensions. So in C++, it might look like this

  struct Greeter {
    virtual void greet() {
      cout greet(); // In C++ prints "sup", but in Swift "Hello, World!"
    delete greeter;
    return 0;
  }

Re: Swift: When Unused Code Is a Bug

#70

Post by delinka »

sharp11 wrote: post #64
delinka wrote: post #62

Providing a protocol with a default concrete implementation of the interface? That's not passing code review here. Would I have caught the bug ? Probably not. But it looks like bad form to me to provide that default implementation to Greeter, so please rewrite your code.

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.

Post reply on HN