[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library
jordan_rose at apple.com
Wed Jan 27 17:29:38 CST 2016
My take: I'm not concerned about this because you won't see it in isolation. It'll always have a boolean expression, and possibly a message as well.
require(offset < self.count)
require(!self.isStarted, "task has already been started")
I can't see anyone getting this confused with the import-like require in other languages. They might not think "require" when they first start using the feature, but they won't think "precondition" either; they'll think "assert" and do a search for "assert in Release builds" or something.
So I think I'm mildly for "require" over "precondition". But that said, I dug up our original rationale for choosing "precondition" (and "preconditionFailure") over "require":
> We think “precondition” is a more precise statement of intent than “require,” and “requirementFailure” is awkward.
> On Jan 27, 2016, at 13:57, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
> But don’t you think any relative advantage of “require” is overshadowed by the potential for confusion since “require” means something completely different in *a lot* of other languages?
> — Radek
>> On 27 Jan 2016, at 22:56, Charles Kissinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> ‘Precondition’ is not particularly bad jargon since it is a standard dictionary word that is used with a similar meaning in areas outside of computer science. ‘Require’ probably has an advantage with students and non-native English speakers by virtue of being a much more commonly used and understood word.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution