你如何设计一个返回(理论上)无限量项目的枚举器？

我正在编写与此类似的代码:

public IEnumerable Unfold(this T seed)
{
    while (true)
    {
        yield return [next (T)object in custom sequence];
    }
}

显然,这种方法永远不会回归.(C#编译器默默地允许这个,而R#给我警告"函数永远不会返回".)

一般来说,提供一个返回无限数量项的枚举器,而不提供停止枚举的方法是不好的设计？

这种情况有什么特别的考虑因素吗？纪念品？PERF？其他陷阱？

如果我们总是提供退出条件,哪些是选项？例如:

类型为T的对象,表示包含或排他的边界

a Predicate continue(同样TakeWhile如此)

伯爵(同样Take)

...

我们应该依赖用户呼叫Take(...)/ TakeWhile(...)之后Unfold(...)吗？(也许是首选方案,因为它利用了现有的Linq知识.)

如果代码将在公共API中发布,无论是按原样(通用)还是作为此模式的特定实现,您会以不同的方式回答这个问题吗？

只要您非常清楚地记录该方法永远不会完成迭代(当然,方法本身很快就会返回),那么我认为这很好.实际上,它可以使一些算法更整洁.我不相信存在任何重要的内存/性能影响 - 尽管如果在迭代器中引用"昂贵"的对象,则会捕获该引用.

总有滥用API的方法:只要你的文档清楚,我认为这很好.

"一般来说,提供一个返回无限量项目的枚举器,而不提供停止枚举的方法,这是不是很糟糕？"

代码的使用者总是可以停止枚举(例如使用break或其他方法).如果您的枚举器返回并且无限序列,这并不意味着枚举器的客户端以某种方式被强制永远不会破坏枚举,实际上您不能创建一个保证由客户端完全枚举的枚举器.

我们应该依赖于在展开(...)之后调用Take(...)/ TakeWhile(...)的用户吗？(也许是首选方案,因为它利用了现有的Linq知识.)

是的,只要您在文档中清楚地指明枚举器返回并且无限顺序和断开枚举是调用者的责任,一切都应该没问题.

返回无限序列并不是一个坏主意,功能编程语言已经做了很长时间了.