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