为什么必须将协议运算符实现为全局函数? [英] Why must a protocol operator be implemented as a global function?

查看:171
本文介绍了为什么必须将协议运算符实现为全局函数?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经看到了这个 Swift Equatable Protocol 问题的答案,提到 = = 方法必须在全局范围内声明。

I've seen the answer to this Swift Equatable Protocol question that mentions how the == method must be declared in the global scope.

如果我不采用 Equatable ,我仍然可以声明 == 来测试我的两种类型之间的相等性。

If I don't adopt Equatable, I still could declare == to test for equality between two of my types.

// extension Foo: Equatable {}

func ==(lhs: Foo, rhs: Foo) -> Bool {
    return lhs.bar == rhs.bar
}

struct Foo {
    let bar:Int
}

需要在全局范围内声明其实现,这使得它似乎偶然 distinct 来自协议,即使采用 Equatable

The fact that its implementation needs to be declared at a global scope, makes it seem incidental to and distinct from a protocol, even if Equatable was adopted.

如何 Equatable 协议除了语法糖以外,只让(我们和)编译器安全地知道我们的类型实现了协议所需的方法吗?

How is the Equatable protocol anything more than syntactic sugar that merely lets (us and) the compiler safely know that our type implemented the required method of the protocol?

为什么运算符实现必须全局声明,即使对于协议也是如此?这是由于调度运算符的方式不同吗?

Why does the operator implementation have to be globally declared, even for a protocol? Is this due to some different way that an operator is dispatched?

推荐答案

更新



从Xcode 8 beta 4发行说明:

UPDATE

From the Xcode 8 beta 4 release notes:


可以在类型或扩展名中定义运算符。例如:

Operators can be defined within types or extensions thereof. For example:

struct Foo: Equatable {
    let value: Int
    static func ==(lhs: Foo, rhs: Foo) -> Bool {
        return lhs.value == rhs.value
    }
}

此类运算符必须声明为 static (或者,在类中, class final ),并且与全球同行相同的
签名。作为此更改的一部分,
协议中声明的运算符要求也必须显式声明 static

Such operators must be declared as static (or, within a class, class final), and have the same signature as their global counterparts. As part of this change, operator requirements declared in protocols must also be explicitly declared static:

protocol Equatable {
    static func ==(lhs: Self, rhs: Self) -> Bool
}




ORIGINAL



这是最近在swift-evolution列表上讨论过(2016-01-31到2016-02-09)。以下是Chris Lattner所说的关于在结构或类范围内声明运算符的内容:

ORIGINAL

This was discussed on the swift-evolution list recently (2016-01-31 through 2016-02-09 so far). Here's what Chris Lattner said, regarding declaring operators in a struct or class scope:


是的,这是一个通常需要的功能(至少对称运算符)。在类声明中动态调度运算符也很有用。我不认为我们有一个坚定的建议,即确定名称查找的工作原理。

Yep, this is a generally desirable feature (at least for symmetric operators). This would also be great to get dynamic dispatch of operators within class declarations. I don’t think we have a firm proposal nailing down how name lookup works with this though.

以后(回复Haravikk) :

And later (replying to Haravikk):



有哪些名称查找问题?你的意思是Foo == Foo的运算符存在于多个位置的情况?

What are the name lookup issues? Do you mean cases where an operator for Foo == Foo exists in more than one location?

是的。名称查找必须有一个定义明确的搜索顺序,
定义阴影和无效的多重定义规则。

Yes. Name lookup has to have a well defined search order, which defines shadowing and invalid multiple definition rules.


我个人认为坚持我们现在拥有的东西,即 - 将特定类/结构中的运算符实现视为全局
无论如何定义,如果同一个签名被多次声明为
,则抛出错误。

Personally I’d just stick with what we have now, i.e- treat operator implementations within a specific class/struct as being globally defined anyway and throw an error if the same signature is declared more than once.

我们需要多个模块才能定义
运营商的实例,我们需要扩展运营商,我们需要追溯
与任何其他成员一致的工作。

We need multiple modules to be able to define instances of an operator, we need operators in extensions, and we need retroactive conformance to work, as with any other member.

这篇关于为什么必须将协议运算符实现为全局函数?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆