[swift-evolution] Compiler should generate code base on the functions that have default values
肇鑫
owenzx at gmail.com
Sun Jan 17 19:34:48 CST 2016
Sorry Andrew, you link is not related with this proposal.
As you can see, this proposal starts with no protocol at all. It starts
with the conflicts between a function with a default value comparing to its
version that has no argument. Then this issue combines with the protocol
limits becomes a larger issue. But there is no two different protocols with
the same properties name here. There is only one protocol from the
beginning to the end.
I also discussed in the link your provided. And in my option, this proposal
has nothing related with that at all.
zhaoxin
On Mon, Jan 18, 2016 at 7:50 AM, Andrew Bennett <cacoyi at gmail.com> wrote:
> Similar has been discussed in the topic: "two protocols with the same
> method name", it starts here:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005673.html
>
> Here's another solution you may not have considered:
>
> struct Foo:A {
>
> func printSomething(something:String = "some thing") {
>
> print(something)
>
> }
>
>
> @implements(A.printSomething)
>
> private func _printSomething() { self.printSomething() }
>
> }
>
>
> This was derived from the message by Joe Groff, in the linked thread:
>
> > Swift's protocol conformance model doesn't rely on the name of the
> member matching the name of the requirement it satisfies. One possibility
> here is to introduce an attribute to explicitly declare what protocol
> requirement(s) a member is intended to satisfy:
> >
> > class X: A, B {
> > @implements(A.ring)
> > var weddingRing: String
> >
> > @implements(B.ring)
> > var ringtone: String
> > }
> >
>
>
>
> On Mon, Jan 18, 2016 at 5:19 AM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hi Dave,
>>
>> I agree with 肇鑫. Your issue and his seem like two separate issues, and
>> I’d also like to see his issue implemented. For example, imagine I wanted
>> to define this protocol:
>>
>> protocol Logger {
>> func print()
>> func print(message: String)
>> func print(path: String)
>> func print(line: Int)
>> func print(message: String, path: String)
>> func print(message: String, line: Int)
>> func print(path: String, line: Int)
>> func print(message: String, path: String, line: Int)
>> }
>>
>> It would be much simpler if I could more simply write:
>>
>> protocol Logger {
>> func print(message: String = default, path: String = default, line:
>> Int = default)
>> }
>>
>> Which is a separate issue then what you propose which would allow the
>> same as the following for *init* as well:
>>
>> protocol Logger {
>> func print(message: String)
>> }
>>
>> class NSLogger {
>> func print(message: String, path: String, line: Int) {
>> // ...
>> }
>> }
>>
>> extension NSLogger: Logger {
>> conformance {
>> print(message)
>> }
>> }
>>
>> On 17 Jan 2016, at 18:09, 肇鑫 via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> It is not to *conform to the same function name but with different
>> signatures*. It is the protocol limits in current Swift. You can
>> implement a protocol function with default values. But the protocol can't
>> call the function with the default value. So you have to add another
>> function that has no argument in the protocol and change the implementation.
>>
>> current code:
>>
>> protocol A {
>> func printSomething(something:String)
>> }
>>
>> struct Foo:A {
>> func printSomething(something:String = "some thing") {
>> print(something)
>> }
>> }
>>
>> Foo().printSomething() // some thing
>> (Foo() as A).printSomething() // Missing argument for parameter #1 in
>> call
>>
>> default value part is widely discussed in this thread
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006798.html>,
>> including other approaches like protocol extension.
>>
>> zhaoxin
>>
>> On Mon, Jan 18, 2016 at 12:52 AM, J. Cheyo Jimenez <cheyo at masters3d.com>
>> wrote:
>>
>>> This is very interesting. The first case seems like a bug because the
>>> compiler should not let you define that function().
>>>
>>> Do you have any actual examples when you would need to conform to the
>>> same function name but with different signatures?
>>>
>>>
>>> On Sunday, January 17, 2016, 肇鑫 via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> This proposal is the summary of the previous protocol function default
>>>> value proposal and some of my new thinkings all together.
>>>>
>>>> Currently the compiler doesn't stop you defining two functions like:
>>>>
>>>> func printSomething(something:String = "some thing") {
>>>> print(something)
>>>> }
>>>>
>>>> func printSomething() {
>>>> print("some thing!")
>>>> }
>>>>
>>>> However, when you call it, an error arises.
>>>>
>>>> printSomething() // Ambiguous use of 'printSomething'
>>>>
>>>> You may say just remove the function that has no argument. But protocol
>>>> needs it.
>>>>
>>>> protocol A {
>>>> func printSomething(something:String)
>>>> func printSomething()
>>>> }
>>>>
>>>> struct Foo:A {
>>>> func printSomething(something:String) {
>>>> print(something)
>>>> }
>>>>
>>>>
>>>> func printSomething() {
>>>> self.printSomething("some thing")
>>>> }
>>>>
>>>> }
>>>>
>>>> If you do't define the no-argument function in protocol A. You can not
>>>> use the function by (Foo() as A).printSomething().
>>>>
>>>>
>>>> As we all know, a function with default values, can rewrite to two or
>>>> more equivalent functions. For example,
>>>>
>>>> struct Bar {
>>>> func add(int1:Int = 1, int2:Int = 2, int3:Int = 3) {
>>>> print(int1 + int2 + int3)
>>>> }
>>>>
>>>> }
>>>>
>>>> is equivalent to
>>>>
>>>> struct Bar {
>>>> func add(int1:Int, int2:Int, int3:Int) {
>>>> print(int1 + int2 + int3)
>>>> }
>>>>
>>>>
>>>> func add() {
>>>> self.add(1, int2: 2, int3: 3)
>>>> }
>>>>
>>>>
>>>> func add(int1:Int) {
>>>> self.add(int1, int2: 2, int3: 3)
>>>> }
>>>>
>>>>
>>>> func add(int1:Int, int2:Int) {
>>>> self.add(int1, int2: int2, int3: 3)
>>>> }
>>>>
>>>> }
>>>>
>>>> So my proposal is let compiler or pre-compiler to generate the code
>>>> internally, without changing the original code, base on the functions that
>>>> have default values.
>>>>
>>>> Then we need not to define multiple functions in a protocol when we
>>>> need function with default values.
>>>>
>>>> new code:
>>>>
>>>> protocol A {
>>>> func printSomething(something:String)
>>>> }
>>>>
>>>> struct Foo:A {
>>>> func printSomething(something:String = "some thing") {
>>>> print(something)
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> If we don't want to change our previous code, we may also need to
>>>> introduce another keyword defaultValue. This keyword is used only in a
>>>> protocol to restrict if a function's argument can have a default value. If
>>>> a function use it, but the implementation doesn't give a default value, or
>>>> vice versa, an error arises.
>>>>
>>>> new code:
>>>>
>>>> protocol A {
>>>> func printSomething(something:String = defaultValue)
>>>> }
>>>>
>>>> struct Foo:A {
>>>> func printSomething(something:String = "some thing") {
>>>> print(something)
>>>> }
>>>>
>>>> }
>>>>
>>>> This keyword is useful. With it, you can still use Swift in old way.
>>>> Which means you need not to change code like below if you don't want to.
>>>>
>>>> old code:
>>>>
>>>> protocol A {
>>>> func printSomething(something:String)
>>>> func printSomething()
>>>> }
>>>>
>>>> struct Foo:A {
>>>> func printSomething(something:String) {
>>>> print(something)
>>>> }
>>>>
>>>>
>>>> func printSomething() {
>>>> self.printSomething("some thing")
>>>> }
>>>>
>>>> }
>>>>
>>>> But if you want to write new code. You can just write it in the new
>>>> way, enjoining the simpler and clearer.
>>>>
>>>> zhaoxin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/d49d2810/attachment.html>
More information about the swift-evolution
mailing list