不透明的返回类型

如果你看一下我的例子，你会发现一些手势意味着myGesture属性将始终实现手势协议，然而，具体的实现类型不需要被调用者知道(它是隐藏的)。body属性也是如此——不是提供具体的类型，而是根据它支持的协议(即View)来描述返回值。

代码如下:

import SwiftUI

struct ContentView: View {
    
    @State private var rotate: Angle = .zero
    
    var myGesture: some Gesture {
        RotationGesture()
            .onChanged { rotate = $0 }
            .onEnded { angle in rotate = angle }
    }
    
    var body: some View {
        Rectangle()
            .frame(width: 200, height: 200)
            .foregroundColor(.blue)
            .rotationEffect(rotate)
            .gesture(myGesture)
    }
}

除此之外，所有应用于矩形的SwiftUI修饰符在返回值时也使用some关键字。例如:

func foregroundColor(_ color: Color?) -> some View

上面Mischa的帖子(抱歉，我还不能直接添加评论)指出，有些是可选的，除非你使用泛型类型，如VStack等。这是因为some是所有视图都能满足的最一般的不透明类型。因此在这里使用它有助于解决编译错误。

它看起来非常接近于Combine的eraseToAnyPublisher()方法。

对于那些被这个主题弄晕的人，这里有一篇非常解密和一步步的文章，感谢Vadim Bulavin。

https://www.vadimbulavin.com/opaque-return-types-and-the-some-keyword-in-swift/

some View是由SE-0244引入的不透明结果类型，在Swift 5.1和Xcode 11中可用。您可以认为这是一个“反向的”通用占位符。

不同于由调用者满足的常规通用占位符:

protocol P {}
struct S1 : P {}
struct S2 : P {}

func foo<T : P>(_ x: T) {}
foo(S1()) // Caller chooses T == S1.
foo(S2()) // Caller chooses T == S2.

不透明的结果类型是由实现满足的隐式泛型占位符，所以你可以这样想:

func bar() -> some P {
  return S1() // Implementation chooses S1 for the opaque result.
}

是这样的:

func bar() -> <Output : P> Output {
  return S1() // Implementation chooses Output == S1.
}

事实上，该特性的最终目标是以这种更显式的形式允许反向泛型，这也将允许您添加约束，例如-> <T:集合> T其中T. element == Int。更多信息请看这篇文章。

这里需要注意的是，返回P的函数返回的是符合P的特定单一具体类型的值，试图在函数中返回不同的符合P的类型会导致编译器错误:

// error: Function declares an opaque return type, but the return
// statements in its body do not have matching underlying types.
func bar(_ x: Int) -> some P {
  if x > 10 {
    return S1()
  } else {
    return S2()
  }
}

因为隐式泛型占位符不能被多种类型所满足。

这与返回P的函数相反，P可以用来表示S1和S2，因为它表示一个任意P符合的值:

func baz(_ x: Int) -> P {
  if x > 10 {
    return S1()
  } else {
    return S2()
  }
}

不透明结果类型> some P比协议返回类型> P有什么好处?

---

1. 不透明的结果类型可以与pat一起使用

目前协议的一个主要限制是pat(具有关联类型的协议)不能用作实际类型。尽管这一限制可能会在该语言的未来版本中被取消，因为不透明结果类型实际上只是泛型占位符，但它们现在可以与pat一起使用。

这意味着你可以做以下事情:

func giveMeACollection() -> some Collection {
  return [1, 2, 3]
}

let collection = giveMeACollection()
print(collection.count) // 3

---

2. 不透明的结果类型具有标识

因为不透明结果类型强制返回一个具体类型，所以编译器知道对同一个函数的两次调用必须返回两个相同类型的值。

这意味着你可以做以下事情:

//   foo() -> <Output : Equatable> Output {
func foo() -> some Equatable { 
  return 5 // The opaque result type is inferred to be Int.
}

let x = foo()
let y = foo()
print(x == y) // Legal both x and y have the return type of foo.

这是合法的，因为编译器知道x和y具有相同的具体类型。这是==的一个重要要求，其中两个参数都是Self类型。

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

这意味着它期望两个值都是与具体符合类型相同的类型。即使Equatable可以作为类型使用，你也不能比较两个任意的Equatable符合类型的值，例如:

func foo(_ x: Int) -> Equatable { // Assume this is legal.
  if x > 10 {
    return 0
  } else {
    return "hello world"      
  }
}

let x = foo(20)
let y = foo(5)
print(x == y) // Illegal.

因为编译器无法证明两个任意的Equatable值具有相同的底层具体类型。

以类似的方式，如果我们引入另一个不透明类型返回函数:

//   foo() -> <Output1 : Equatable> Output1 {
func foo() -> some Equatable { 
  return 5 // The opaque result type is inferred to be Int.
}

//   bar() -> <Output2 : Equatable> Output2 {
func bar() -> some Equatable { 
  return "" // The opaque result type is inferred to be String.
}

let x = foo()
let y = bar()
print(x == y) // Illegal, the return type of foo != return type of bar.

这个例子是非法的，因为尽管foo和bar都返回一些Equatable，但它们的“反向”泛型占位符Output1和Output2可以由不同的类型满足。

---

3.不透明的结果类型由泛型占位符组成

与常规协议类型的值不同，不透明结果类型与常规的泛型占位符组合得很好，例如:

protocol P {
  var i: Int { get }
}
struct S : P {
  var i: Int
}

func makeP() -> some P { // Opaque result type inferred to be S.
  return S(i: .random(in: 0 ..< 10))
}

func bar<T : P>(_ x: T, _ y: T) -> T {
  return x.i < y.i ? x : y
}

let p1 = makeP()
let p2 = makeP()
print(bar(p1, p2)) // Legal, T is inferred to be the return type of makeP.

如果makeP只是返回P，这将无法工作，因为两个P值可能具有不同的底层具体类型，例如:

struct T : P {
  var i: Int
}

func makeP() -> P {
  if .random() { // 50:50 chance of picking each branch.
    return S(i: 0)
  } else {
    return T(i: 1)
  }
}

let p1 = makeP()
let p2 = makeP()
print(bar(p1, p2)) // Illegal.

---

为什么使用不透明的结果类型而不是具体类型?

这时你可能会想，为什么不直接把代码写成这样:

func makeP() -> S {
  return S(i: 0)
}

不透明结果类型的使用允许您通过只公开P提供的接口来使类型S成为实现细节，从而使您可以灵活地在后面更改具体类型，而不会破坏依赖于函数的任何代码。

例如，你可以替换:

func makeP() -> some P {
  return S(i: 0)
}

:

func makeP() -> some P { 
  return T(i: 1)
}

而不会破坏任何调用makeP()的代码。

有关此特性的进一步信息，请参阅语言指南的不透明类型部分和Swift进化建议。

另一个答案很好地解释了新some关键字的技术方面，但这个答案将试图简单地解释为什么。

---

假设我有一个协议动物，我想比较两个动物是否是兄弟姐妹:

protocol Animal {
    func isSibling(_ animal: Self) -> Bool
}

这样，如果两个动物是同一类型的动物，那么比较它们是否是兄弟姐妹才有意义。

---

现在我举一个动物的例子供大家参考

class Dog: Animal {
    func isSibling(_ animal: Dog) -> Bool {
        return true // doesn't really matter implementation of this
    }
}

没有T的方式

现在，假设我有一个函数，从一个“家族”中返回一个动物。

func animalFromAnimalFamily() -> Animal {
    return myDog // myDog is just some random variable of type `Dog`
}

注意:这个函数实际上不会编译。这是因为在添加'some'特性之前，如果协议使用'Self'或泛型，则不能返回协议类型。但是假设你可以…假设这将myDog向上转换为抽象类型Animal，让我们看看会发生什么

现在问题来了，如果我试着这么做:

let animal1: Animal = animalFromAnimalFamily()
let animal2: Animal = animalFromAnimalFamily()

animal1.isSibling(animal2) // error

这将抛出一个错误。

为什么?原因是，当你调用animal1.isSibling(animal2)时，Swift不知道这些动物是狗、猫还是什么。据斯威夫特所知，animal1和animal2可能是不相关的动物物种。因为我们不能比较不同类型的动物(见上文)。这会出错

某个T如何解决这个问题

让我们重写之前的函数:

func animalFromAnimalFamily() -> some Animal {
    return myDog
}

let animal1 = animalFromAnimalFamily()
let animal2 = animalFromAnimalFamily()

animal1.isSibling(animal2)

animal1和animal2不是Animal，但它们是实现Animal的类。

这让你现在做的是，当你调用animal1. issibling (animal2)时，Swift知道animal1和animal2是同一类型。

所以我喜欢这样思考:

一些T让Swift知道T的什么实现正在被使用，但类的用户不知道。

(自我推销免责声明)我已经写了一篇博客文章，更深入地讨论了这个新功能(例子和这里一样)

在我的理解中(可能是错误的)

这是我拥有的

Protocol View{}

 class Button: View { // subclass of View } 

 //this class not a subclass of View
 class ButtonBuilder<T> where T:View { //using T as View here   } 

Then

var body: View = Button() // ok
var body: View = ButtonBilder() //not ok
var body: some View = ButtonBilder() //ok

So

一些协议

使用该协议的泛型类是否可以在自己的代码中作为协议的子类处理