I’m not quite sure what you mean by "restrictions of parent implementations”,
however, the “default value” you’re mentioning is a fundamental part of
OOP–when a subclass overrides a superclass, it gets the parent class’s methods
for free. There’s no need to issue a warning for this, since it’s expected
behavior from other Object-Oriented languages.
Saagar Jha
> On Jan 4, 2017, at 6:29 PM, Wagner Truppel via swift-users
> <swift-users@swift.org> wrote:
>
> Hello,
>
> I wasn’t sure whether to post this message here, at swift-dev, or at
> swift-evolution. so I’ll try here first. Hopefully it will get to the right
> group of people or, if not, someone will point me to the right mailing list.
>
> I came across a situation that boils down to this example:
>
> class Parent {
> func foo() {
> print("Parent foo() called")
> }
> }
>
> class Child: Parent {
> func foo(x: Int = 0) {
> print("Child foo() called")
> }
> }
>
> let c = Child()
> c.foo() // prints "Parent foo() called"
>
> I understand why this behaves like so, namely, the subclass has a method
> foo(x:) but no direct implementation of foo() so the parent’s implementation
> is invoked rather than the child's. That’s all fine except that it is not
> very intuitive.
>
> I would argue that the expectation is that the search for an implementation
> should start with the subclass (which is does) but should look at all
> possible restrictions of parent implementations, including the restriction
> due to default values.
>
> At the very least, I think the compiler should emit a warning or possibly
> even an error.
>
> Thanks for reading.
> Cheers,
>
> Wagner
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
