Indeed, and in this case as well the compiler issues no warning even though the
ambiguity is evident. I had to try it on a playground to be sure that it’s the
parameter-less foo() rather than the default-argumented foo(x:) that gets
invoked when we call foo() on an instance.
Of course, both this ambiguity and the one I started with can be resolved by
explicitly calling foo(x: 0) but, as that link points out, "What is the point
of having an optional parameter (a parameter with a default value) if you have
to supply it anyway?”
More importantly, it’s an easy mistake to expect one implementation to be
invoked rather than the other, with a potentially costly impact. The compiler
has enough information to catch this and I think it should.
Wagner
> On 5 Jan 2017, at 03:54, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
>
> The same ambiguity occurs even without inheritance:
>
> class C {
> func foo() {}
> func foo(x: Int = 0) {}
> }
>
> Somewhat related: https://bugs.swift.org/browse/SR-1408
>
>
> On Wed, Jan 4, 2017 at 7:42 PM, Wagner Truppel via swift-users
> <swift-users@swift.org> wrote:
> I’m afraid I wasn’t clear enough on my post. The default value I referred to
> is the “= 0”. Had it been absent, the call c.foo() would undeniably be
> fulfilled by the parent class. However, with the default argument value, it’s
> not obvious whether c.foo() should be the parent’s implementation or the
> child’s implementation (with the argument set to the default value). That’s
> why I’m suggesting a compiler warning because it’s very easy to make the
> mistake of calling c.foo() expecting the child’s implementation and it may be
> a hard bug to track when it happens.
>
> Wagner
>
>
>> On 5 Jan 2017, at 03:35, Saagar Jha <saa...@saagarjha.com> wrote:
>>
>> 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
>
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
