何时不使用deleteToAnyPublisher

如何解决何时不使用deleteToAnyPublisher

结合似乎是在清除类型的情况下构建的。原因之一是要避免由许多链式运算符生成的复杂类型，例如此question中定义的解释。

我很好奇您可能不想打电话给eraseToAnyPublisher()的情况。我想到了一个可能的候选人：

func fetchResource() -> Future<Model,Error>

在这种情况下，fetchResource并不意味着发出多次，并且返回类型为Future可以使功能更清晰。

您还可以返回AnyPublisher：

func fetchResource() -> AnyPublisher<Model,Error>

这使您可以对使用者隐藏实施细节并防止滥用。不过，这是一个折衷方案……消费者不会知道Future的语义：

• Future一经创建便立即执行，而有些发布商只有在订阅时才发出 值
• Future保留其最终结果，并将价值分享/重放给任何未来的订户

任何人都知道您何时不会eraseToAnyPublisher()的好例子吗？

解决方法

1. AnyPublisher只是一个临时解决方案，直到我们能够为不透明类型添加约束。

例如这个...

var publisher: AnyPublisher<Int,Never> { .init(Just(1)) }

...实际上应该是这样的：

var publisher<Publisher: Combine.Publisher>: some Publisher
where Publisher.Output == Int,Publisher.Failure == Never {
  Just(1)
}

您会在Swift论坛上找到很多关于如何实现不容易（以及使用哪种语法！）的讨论，因此为什么我们仍在使用公共类型擦除类型的中间解决方案。 / p>

---

1. Future和Publisher之间没有协议。这就是您要的问题所在。如果您想执行更严格的合同，请在继承的协议中添加一些内容……

protocol Futurey: Publisher {
extension Future: Futurey {

...然后，不幸的是，您将不得不创建另一个擦除类型。现在。

struct AnyFuturey<Output,Failure> {