[Pitch] Allow default parameter overrides

[hlovatt (Howard Lovatt)]

@xwu

When I look at a method defined in the superclass, every part of the signature should apply when I call it.

If this turns out to be confusing, as I said before, the only consistent rule would be to ban contradictory default values in subclasses, but that’s a big change.

The concept that the default value is part of the signature is just one way of handling default arguments, and most people in this discussion seem to be saying not a good way.

Most languages, all the dynamic languages (obviously) and some static languages like Scala, would behave as though the default was not part of the signature and instead be a shorthand for defining multiple methods. And as numerous example have pointed out this is a superior interpretation/way.

A key part of this argument, rather than saying that is how I interpret them because I am used to languages that do it that way, how about why is that interpretation superior to what the majority of languages do and what the majority of people expect.

[xwu (Xiaodi Wu)]

@xwu

When I look at a method defined in the superclass, every part of the signature should apply when I call it.

@Nevin

When I look at a method overridden in a subclass, every part of that override should apply when I call it.

It does! Both of these hold true! I think you're misunderstanding the example here. Let's write it out more clearly:

class C {
  func f(_ i: Int = 42) {
    print(i, "c")
  }

  init() { }
}

class D : C {
  override func f(_ i: Int = 21) {
    print(i, "d")
  }
}

let c = C()
c.f() // 42 c

let d = D()
d.f() // 21 d

let dAsC = d as C
dAsC.f() // 42 d

@Nevin

Please let’s refrain from hyperbolic states like “the only consistent rule would be X”. Clearly there is at least one other consistent rule, namely to have overrides actually, you know, override the superclass version.

Yes, of course there is that other consistent rule--we have that currently. Override implementations actually do override the superclass implementation. But it seems this is consistent and confusing. Hence, there's the alternative: remove the feature, and then there's no more confusion while still preserving consistency.

[hlovatt (Howard Lovatt)]

@jetmax25

protocol OverridePrintProtocol {
func printTest(param : String)
}

extension OverridePrintProtocol {
func printTest(param : String = "Ex Default") {
print("extension logic: (param)")
}
}

class ImplementationClass : OverridePrintProtocol {
func printTest(param : String = "Class Default") {
print("Class logic: (param)")
}
}

Great example of the current inconsistency, I am to treat default values as part of the signature yet I can define them in a protocol, but can in an extension! The default case is statically dispatched but the non default isn't!

If the interpretation where shorthand for multiple methods then:

protocol OverridePrintProtocol2 {
    func printTest()
    func printTest(param : String)
}

extension OverridePrintProtocol2 {
    func printTest() {
        printTest(param: "Ex Default 2")
    }
    func printTest(param : String) {
        print("extension logic 2: \(param)")
    }
}

class ImplementationClass2 : OverridePrintProtocol2 {
    func printTest() {
        printTest(param: "Class Default 2")
    }
    func printTest(param : String) {
        print("Class logic 2: \(param)")
    }
}

let overrideTest2 : OverridePrintProtocol2 = ImplementationClass2()
overrideTest2.printTest() // Class logic 2: Class Default 2
overrideTest2.printTest(param: "anything") // Class logic 2: anything

Which is what most people would expect and it would also be consistent with protocols not having definitions since the protocol like now doesn't include the default, but this is no longer confusing since the default isn't part of the protocol.

[xwu (Xiaodi Wu)]

@hlovatt

The concept that the default value is part of the signature is just one way of handling default arguments, and most people in this discussion seem to be saying not a good way.

Most languages, all the dynamic languages (obviously) and some static languages like Scala, would behave as though the default was not part of the signature and instead be a shorthand for defining multiple methods. And as numerous example have pointed out this is a superior interpretation/way.

A key part of this argument, rather than saying that is how I interpret them because I am used to languages that do it that way, how about why is that interpretation superior to what the majority of languages do and what the majority of people expect.

I disagree that this is a matter of opinion. The signature is what it is. It's visible and made up of text; among that text are default values. You see it--it's literally (in every sense of literally) there. You can't just will that away.

[hlovatt (Howard Lovatt)]

@xwu

let dAsC = d as C
dAsC.f() // 42 d

Nevin:

1st that is exactly the same example we started with, so I don't see what reframing the example achieves.

2nd it is confusing, it prints "42 d" not "42 c" (note change from d to c). So despite been dAsC it is not C its a hybrid of D and C.

[xwu (Xiaodi Wu)]

@jetmax25

Protocols handle overrides in a different way as well

protocol OverridePrintProtocol {
    func printTest(param : String)
}

extension OverridePrintProtocol {
    func printTest(param : String = "Ex Default") {
        print("extension logic: \(param)")
    }
}

class ImplementationClass : OverridePrintProtocol {
    func printTest(param : String = "Class Default") {
        print("Class logic: \(param)")
    }
}

Because default values are part of the signature, so too is its absence. Since printTest() without an argument isn't part of the protocol requirements (and currently can't be--we can make that additive change though), printTest() without an argument is statically dispatched and can only be shadowed, not overridden.

Yes, this is confusing. We can definitely improve the diagnostics and clarify these rules.

[hlovatt (Howard Lovatt)]

@xwu

I disagree that this is a matter of opinion. The signature is what it is. It’s visible and made up of text; among that text are default values. You see it–it’s literally (in every sense of literally) there. You can’t just will that away.

By that argument then the following shouldn't be allowed:

class B {
    var ex = 1
}
class D: B {
    override init() {
        super.init()
        ex = 2
    }
}
let dAsB: B = D()
print(dAsB.ex) // 2

Since ex = 1 is part of the signature, "You see it–it’s literally (in every sense of literally) there. You can’t just will that away.", then the above shouldn't be allowed. Your argument makes no sense, in functions the = xxx is part of the signature but in the rest of the language that very same syntax isn't!

[xwu (Xiaodi Wu)]

@hlovatt

1st that is exactly the same example we started with, so I don’t see what reframing the example achieves.

2nd it is confusing, it prints “42 d” not “42 c” (note change from d to c). So despite been dAsC it is not C its a hybrid of D and C.

And that's the whole crux of signature vs. implementation. let d = D(), dAsC = d as C means:

I've got an instance of D, now let me use the "guts" (implementation) of D with the "face" (API, or in other words, the method signature) of C.

The same thing happens with covariance:

class Animal {
  func f() -> (String, Animal) {
    return ("blorp", self)
  }

  init() { }
}

class Cow : Animal {
  override func f() -> (String, Cow) {
    return ("moo", self)
  }
}

let cow = Cow(), cowAsAnimal = cow as Animal
print(type(of: cow.f), cow.f().0) // () -> (String, Cow) moo
print(type(of: cowAsAnimal.f), cow.f().0) // () -> (String, Animal) moo

[xwu (Xiaodi Wu)]

@hlovatt

Since ex = 1 is part of the signature, “You see it–it’s literally (in every sense of literally) there. You can’t just will that away.”, then the above shouldn’t be allowed. Your argument makes no sense, in functions the = xxx is part of the signature but in the rest of the language that very same syntax isn’t!

That's clearly a faulty argument, because in making it you've willed away the other part of the signature: var.

var tells you everything you need to know about why ex can be some other value. Swift lets you change it because, in the contract that's the signature, you literally said that you reserved the right to do so.

Now change that var to let and see what happens.

[hlovatt (Howard Lovatt)]

But we are not talking about a final function which would be the nearest equivalent of a let, var is closest to an overridable function. The analogy isn't perfect, non are they are after all analogies. The point is you are happy for a variable not to be tied to its default value but not an argument, which is after all very similar.

[Nevin]

@xwu

Yes, of course there is that other consistent rule–we have that currently. Override implementations actually do override the superclass implementation. But it seems this is consistent and confusing. Hence, there’s the alternative: remove the feature, and then there’s no more confusion while still preserving consistency.

…and there is a third option, where the override’s default argument takes precedence as proposed in this thread, which is also consistent.

Acting as though that option does not exist, is entirely unhelpful and does not advance the discussion.

[xwu (Xiaodi Wu)]

@Nevin

…and there is a third option, where the override’s default argument takes precedence as proposed in this thread, which is also consistent.

Acting as though that option does not exist, is entirely unhelpful and does not advance the discussion.

I've acknowledged this option's existence, but it's certainly not consistent: subclasses cannot change the signature of superclasses, as I've already said.

[hlovatt (Howard Lovatt)]

@xwu

let cow = Cow(), cowAsAnimal = cow as Animal
print(type(of: cow.f), cow.f().0) // () -> (String, Cow) moo
print(type(of: cowAsAnimal.f), cow.f().0) // () -> (String, Animal) moo

This is the behaviour everyone wants, they want "moo" even though it is typed Animal.

[xwu (Xiaodi Wu)]

@hlovatt

This is the behaviour everyone wants, they want “moo” even though it is typed Animal.

I think you misunderstand the example; "moo" is typed String.

[hlovatt (Howard Lovatt)]

Yes I know. But "moo" comes from the derived class just like the default argument should even though the Cow object has been type cast to Animal. (Actually there is a mistake in the code but we all know what you mean.)

[xwu (Xiaodi Wu)]

@hlovatt

But we are not talking about a final function which would be the nearest equivalent of a let, var is closest to an overridable function. The analogy isn’t perfect, non are they are after all analogies. The point is you are happy for a variable not to be tied to its default value but not an argument, which is after all very similar.

The value of an instance variable is not part of the API of the type; if it's a let binding, then arguably it could be, but with a var binding it cannot be for obvious reasons. The signature of a method, of which default values are a part, is a part of the API of the type.

[xwu (Xiaodi Wu)]

@hlovatt

Yes I know. But “moo” comes from the derived class just like the default argument should even though the Cow object has been type cast to Animal. (Actually there is a mistake in the code but we all know what you mean.)

The code runs as-is and produces the result indicated (Xcode 9.3b4).

"moo" comes from the body of the method; the type comes from its signature. Default arguments are in the signature. I don't know what we're disagreeing about anymore at this point.

[Nevin]

@xwu

I’ve acknowledged this option’s existence, but it’s certainly not consistent: subclasses cannot change the signature of superclasses, as I’ve already said.

It is entirely consistent, just a different set of rules.

If you have reasons for why one set of rules is preferable, in the context of designing a language for use by actual human programmers, by all means please share those reasons.

Merely stating “default arguments are part of the signature” is not effective, because the proposal is exactly to *change* how that works. If you think it should stay working as it does today, then please explain *why* you prefer the current behavior, rather than just repeatedly stating what the current behavior is.

[hlovatt (Howard Lovatt)]

@xwu

if it’s a let binding, then arguably it could be

So in this world the following would have different type signatures:

class C1 {
    let c = 1
}
class C2 {
    let c: Int
    init() { c = 1 }
}

Come off it!

[xwu (Xiaodi Wu)]

@Nevin

It is entirely consistent, just a different set of rules.

If you have reasons for why one set of rules is preferable, in the context of designing a language for use by actual human programmers, by all means please share those reasons.

Merely stating “default arguments are part of the signature” is not effective, because the proposal is exactly to change how that works. If you think it should stay working as it does today, then please explain why you prefer the current behavior, rather than just repeatedly stating what the current behavior is.

I wasn't aware that you were proposing to change the rules.

You called the behavior [edit for clarity: behavior of override functions] a bug, and I explained why in fact it's not: it's consistent with the current design of Swift [edit for clarity: the current design of Swift wherein default values are part of the method signature]. I have no opinion whatsoever about whether the current design is good (in fact, I agree that it can be confusing); I'm just explaining over and over again what it is because there seems to be pervasive confusion about it.

If you understand what it is today and want to change it, then it's up to you to explain why such a change would be superior. Unless I'm mistaken, supporting default values as part of the signature is part of this whole business of moving away from tuples-as-argument-lists that also removed implicit tuple splatting, argument shuffle, etc. If I'm right, then it's a deliberate recent change, and reverting it isn't in the cards.