Ahh, I get what you’re saying now. In this case I’d like to see a warning when
a “conflicting” function is defined that there may be potential ambiguity.
Saagar Jha
> On Jan 4, 2017, at 8:19 PM, Wagner Truppel <tru...@gmail.com> wrote:
>
> 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
