Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

Issued created: https://bugs.swift.org/browse/SR-3700


> On 23 Jan 2017, at 10:24, Quinn The Eskimo! via swift-users 
>  wrote:
> 
>> what’s the best way to get this request to the people who can make it happen
> 
> File a Swift bug report.
> 
> 
> 
> Please post your bug number, just for the record.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> 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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Zhao Xin via swift-users]

I doubt if you could have done that in swift-evolution list. As for an
evolution, it requests that you not only provides the question, but also
must provide the answer and how to implementing in code together.

Zhaoxin

On Mon, Jan 23, 2017 at 6:04 PM, Wagner Truppel via swift-users <
swift-users@swift.org> wrote:

> Right, so several people have agreed with me that a compiler warning is in
> order. My question now is: what’s the best way to get this request to the
> people who can make it happen? swift-dev list? swift-evolution list? Apple
> radar? Suggestions are welcome.
>
> Thanks.
> Wagner
>
>
> > On 9 Jan 2017, at 09:49, David Hart  wrote:
> >
> > I think we need a warning because it is definitely ambiguous and a
> common pitfall for users of an API. The only solution would be for the APIs
> be written so to avoid those ambiguities I think.
> >
> >> On 5 Jan 2017, at 08:58, Rien via swift-users 
> wrote:
> >>
> >> As you know. there is no ambiguity, no warnings needed.
> >> (The parameter is part of the identifier of the function)
> >>
> >> Imo, this request falls into the category “do as I think, not as I say”.
> >>
> >> That is a discussion without end. Personally I am against ANY warnings
> of this kind. The reason is that I want my code to compile warnings free
> (default compiler behaviour) and I do not want an extra pragma in the code
> to instruct the compiler that when I am calling “foo()” I do indeed want to
> call “foo()”.
> >>
> >> Regards,
> >> Rien
> >>
> >> Site: http://balancingrock.nl
> >> Blog: http://swiftrien.blogspot.com
> >> Github: http://github.com/Swiftrien
> >> Project: http://swiftfire.nl
> >>
> >>
> >>
> >>
> >>> On 05 Jan 2017, at 03:29, 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
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

Ah, excellent! Thanks! Will do shortly.

> On 23 Jan 2017, at 10:24, Quinn The Eskimo! via swift-users 
>  wrote:
> 
>> what’s the best way to get this request to the people who can make it happen
> 
> File a Swift bug report.
> 
> 
> 
> Please post your bug number, just for the record.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> 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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[David Hart via swift-users]

I think we need a warning because it is definitely ambiguous and a common 
pitfall for users of an API. The only solution would be for the APIs be written 
so to avoid those ambiguities I think.

> On 5 Jan 2017, at 08:58, Rien via swift-users  wrote:
> 
> As you know. there is no ambiguity, no warnings needed.
> (The parameter is part of the identifier of the function)
> 
> Imo, this request falls into the category “do as I think, not as I say”.
> 
> That is a discussion without end. Personally I am against ANY warnings of 
> this kind. The reason is that I want my code to compile warnings free 
> (default compiler behaviour) and I do not want an extra pragma in the code to 
> instruct the compiler that when I am calling “foo()” I do indeed want to call 
> “foo()”.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Kenny Leung via swift-users]

Hi All.

I think this is a case of ambiguity that the compiler is not catching at the 
call site. Consider this example:

private class DefaultValues {

// If this method exists, it compiles and it called.
// If this method does not exist, the code in the test says, "Ambiguous use 
of 'guous'
/*
public func guous() {
print("guous")
}
*/

public func guous(x:Int=0) {
print("guous x:")
}

public func guous(y:Int=1) {
print("guous y:")
}

}

class DefaultValuesTests: XCTestCase {

func testDefaultValueAmbiguity() {
let ambi = DefaultValues()
ambi.guous()
}

}
 
If the no-arg method doesn’t exist, the test does not compile. There is an 
error at the call site saying, “Ambiguous use of ‘guous’”. If the no-arg method 
does exist, it is preferred, and the code compiles and runs, even though the 
ambiguity still exists. 

I think this should be classified as a compiler bug where it should be 
including no-arg methods and methods with default args to consider if they are 
ambiguous at the call site, not at the definition point.

-Kenny


> On Jan 5, 2017, at 3:17 AM, Wagner Truppel via swift-users 
>  wrote:
> 
> Exactly.
> 
> I would only add that renaming might not be the correct solution in some 
> cases as, then,  instances of the subclass would still be able to invoke the 
> superclass method and that might not always be acceptable.
> 
> Wagner
> 
>> On 5 Jan 2017, at 11:09, Frank O'Dwyer  wrote:
>> 
>> I think there is a clear case for a warning here, in that the introduction 
>> of a default parameter value in such cases is in effect an empty promise and 
>> just introduces unreachable code. Indeed 'unreachable code' should perhaps 
>> be the warning.
>> 
>> This is because as soon as there is a foo() method, whether by inheritance 
>> or a definition in the same class, it renders it impossible to invoke 
>> foo(x:) with its default value in the normal way, or in any interesting way. 
>> In fact it makes no difference at all if the default is 0, 3, or 5, or not 
>> written in the first place. You now have to be explicit. Therefore, adding 
>> the default seems to provide no utility at all and can only lead to the 
>> confusion the OP is talking about, and bugs. Furthermore it seems like a 
>> very loud indication that the programmer expected something else to happen 
>> and it violates the 'principle of least surprise' for anyone else reading 
>> the code.
>> 
>> Given all that, it seems like the syntactic vinegar of having to write a 
>> pragma to get a clean compile would be appropriate. It alerts other readers 
>> of the code that 'here be dragons', and it tells the code author that they 
>> should probably achieve what they intend in another way. Most likely, by 
>> renaming foo(), or removing the useless default for foo(x:).
>> 
>> Cheers,
>> Frank
>> 
>>> On 5 Jan 2017, at 07:58, Rien  wrote:
>>> 
>>> As you know. there is no ambiguity, no warnings needed.
>>> (The parameter is part of the identifier of the function)
>>> 
>>> Imo, this request falls into the category “do as I think, not as I say”.
>>> 
>>> That is a discussion without end. Personally I am against ANY warnings of 
>>> this kind. The reason is that I want my code to compile warnings free 
>>> (default compiler behaviour) and I do not want an extra pragma in the code 
>>> to instruct the compiler that when I am calling “foo()” I do indeed want to 
>>> call “foo()”.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
 On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
  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 

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

Exactly.

I would only add that renaming might not be the correct solution in some cases 
as, then,  instances of the subclass would still be able to invoke the 
superclass method and that might not always be acceptable.

Wagner

> On 5 Jan 2017, at 11:09, Frank O'Dwyer  wrote:
> 
> I think there is a clear case for a warning here, in that the introduction of 
> a default parameter value in such cases is in effect an empty promise and 
> just introduces unreachable code. Indeed 'unreachable code' should perhaps be 
> the warning.
> 
> This is because as soon as there is a foo() method, whether by inheritance or 
> a definition in the same class, it renders it impossible to invoke foo(x:) 
> with its default value in the normal way, or in any interesting way. In fact 
> it makes no difference at all if the default is 0, 3, or 5, or not written in 
> the first place. You now have to be explicit. Therefore, adding the default 
> seems to provide no utility at all and can only lead to the confusion the OP 
> is talking about, and bugs. Furthermore it seems like a very loud indication 
> that the programmer expected something else to happen and it violates the 
> 'principle of least surprise' for anyone else reading the code.
> 
> Given all that, it seems like the syntactic vinegar of having to write a 
> pragma to get a clean compile would be appropriate. It alerts other readers 
> of the code that 'here be dragons', and it tells the code author that they 
> should probably achieve what they intend in another way. Most likely, by 
> renaming foo(), or removing the useless default for foo(x:).
> 
> Cheers,
> Frank
> 
>> On 5 Jan 2017, at 07:58, Rien  wrote:
>> 
>> As you know. there is no ambiguity, no warnings needed.
>> (The parameter is part of the identifier of the function)
>> 
>> Imo, this request falls into the category “do as I think, not as I say”.
>> 
>> That is a discussion without end. Personally I am against ANY warnings of 
>> this kind. The reason is that I want my code to compile warnings free 
>> (default compiler behaviour) and I do not want an extra pragma in the code 
>> to instruct the compiler that when I am calling “foo()” I do indeed want to 
>> call “foo()”.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>>  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Frank O'Dwyer via swift-users]

I think there is a clear case for a warning here, in that the introduction of a 
default parameter value in such cases is in effect an empty promise and just 
introduces unreachable code. Indeed 'unreachable code' should perhaps be the 
warning.

This is because as soon as there is a foo() method, whether by inheritance or a 
definition in the same class, it renders it impossible to invoke foo(x:) with 
its default value in the normal way, or in any interesting way. In fact it 
makes no difference at all if the default is 0, 3, or 5, or not written in the 
first place. You now have to be explicit. Therefore, adding the default seems 
to provide no utility at all and can only lead to the confusion the OP is 
talking about, and bugs. Furthermore it seems like a very loud indication that 
the programmer expected something else to happen and it violates the 'principle 
of least surprise' for anyone else reading the code.

Given all that, it seems like the syntactic vinegar of having to write a pragma 
to get a clean compile would be appropriate. It alerts other readers of the 
code that 'here be dragons', and it tells the code author that they should 
probably achieve what they intend in another way. Most likely, by renaming 
foo(), or removing the useless default for foo(x:).

Cheers,
Frank

> On 5 Jan 2017, at 07:58, Rien  wrote:
> 
> As you know. there is no ambiguity, no warnings needed.
> (The parameter is part of the identifier of the function)
> 
> Imo, this request falls into the category “do as I think, not as I say”.
> 
> That is a discussion without end. Personally I am against ANY warnings of 
> this kind. The reason is that I want my code to compile warnings free 
> (default compiler behaviour) and I do not want an extra pragma in the code to 
> instruct the compiler that when I am calling “foo()” I do indeed want to call 
> “foo()”.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Rien via swift-users]

As you know. there is no ambiguity, no warnings needed.
(The parameter is part of the identifier of the function)

Imo, this request falls into the category “do as I think, not as I say”.

That is a discussion without end. Personally I am against ANY warnings of this 
kind. The reason is that I want my code to compile warnings free (default 
compiler behaviour) and I do not want an extra pragma in the code to instruct 
the compiler that when I am calling “foo()” I do indeed want to call “foo()”.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Saagar Jha via swift-users]

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  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  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 
>>  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  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 
  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

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  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 
>  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  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 
>>>  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Jacob Bandes-Storch via swift-users]

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  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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Saagar Jha via swift-users]

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 
>  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] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

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