[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library

Jordan Rose 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/d4e1af37/attachment.html>

More information about the swift-evolution mailing list