allow overriding functions to have additional para...
# language-proposals
l
allow overriding functions to have additional parameters with default values
Copy code
interface I {
	fun foo(x: Int)
}

class C : I {
	override fun foo(x: Int, y: Int = 0) {}
}
basically sugar for
Copy code
override fun foo(x: Int) = foo(x, 0)
fun foo(x: Int, y: Int) {}
t
No... This breaks the whole point of
override
.
l
how so
t
Because the number of parameters don't match, and when you override something you expect them to. A parameter with a default value is still a parameter.
l
can you give an example where this becomes a problem?
t
Because it literally makes no sense, the parameters don't match, therefore it would be impossible to override. I can't think of any issues at the top of my head, but I'm sure there are some.
l
that's not very helpful
t
How so? Do you disagree with what I've said, if so, why?
l
you're basically saying that there is a rule that this proposal breaks, and explain that rule with itself. reasoning in the form of "you can't change the number of parameters because the number of parameters must be the same" is circular, you're just begging the question of course there could be something else that relies on the number of parameters never changing, but you said yourself that you cannot think of anything that does, so i don't get why you're so certain that it wouldn't work
m
I think this does make complete sense. It really looks like there can be some issues somewhere but I also can't think of any. A strong point is that it becomes a simple sugar for a construct that is totally fine already.
👍 1
l
• What's the behavior like if there are a few more optional parameters, like
fun foo(a: Int, b: Int = 1, c: String = "2")
? Should it override all the couterparts like
foo(a)
,
foo(a, b)
,
foo(a, b, c)
,
foo(b, c)
? • If we have both
fun foo(x)
and
fun foo(x, y)
in parent,
override fun foo(x, y = 1)
overrides only foo(a, b)? or overrides both?
☝️ 1
☝🏻 1
l
1) no, there is still only 1 inherited function to override 2) darn, that's a valid point. can't think of any way to make it work
s
I think on 2) you could have a conflicting overrides error, similar to what you get when you try to have a
val something
, and a
fun getSomething
in the same class
m
You can't have
fun foo(x)
and `fun foo(x = 1)`anyway, so 2) should not be supported for override