The right first step is to raise a bug on JIRA https://bugs.swift.org <https://bugs.swift.org/> with the example test case in the mail. It will then be assigned to the appropriate individuals and prioritised/fixed accordingly.
Alex > On 23 Jan 2017, at 10:04, 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 <da...@hartbit.com> 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 <swift-users@swift.org> 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
