对unsafePerformIO的部门限制 [英] Departmental restriction against unsafePerformIO

问题描述

在工作中有一些讨论，使它成为一个部门范围的政策，禁止使用 unsafePerformIO 及其类似的。就个人而言，我并不介意，因为我一直认为，如果我发现自己想使用它，通常意味着我需要重新思考我的方法。

There has been some talk at work about making it a department-wide policy of prohibiting the use of unsafePerformIO and its ilk. Personally, I don't really mind as I've always maintained that if I found myself wanting to use it, it usually meant that I need to rethink my approach.

这个限制是否合理？我似乎记得在某个地方读到它主要是为FFI，但我不记得我在哪里读的那一刻。

Does this restriction sound reasonable? I seem to remember reading somewhere that it was included mainly for FFI, but I can't remember where I read that at the moment.

编辑：
Ok ， 那是我的错。它不会被限制在合理需要的地方，即。 FFI。

edit: Ok, that's my fault. It wouldn't be restricted where it's reasonably needed, ie. FFI. The point of the policy is more to discourage laziness and code smells.

推荐答案

很多核心库如 ByteString 使用 unsafePerformIO ，例如自定义内存分配。

A lot of core libraries like ByteString use unsafePerformIO under the hood, for example to customize memory allocation.

当您使用这样的库时，您相信库的作者已经证明了它们导出的API的引用透明度，并且记录了用户的任何必要的前提条件。您的部门应制定政策和审查流程，以在内部提供类似的保证，而不是全面禁止。

When you use such a library, you're trusting that the library author has proven the referential transparency of their exported API, and that any necessary preconditions for the user are documented. Rather than a blanket ban, your department should establish a policy and a review process for making similar assurances internally.

这篇关于对unsafePerformIO的部门限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！