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

Jordan Rose jordan_rose at apple.com
Wed Jan 27 17:33:49 CST 2016


> On Jan 26, 2016, at 18:06, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> 
>> on Tue Jan 26 2016, Charles Kissinger <swift-evolution at swift.org> wrote:
>> 
>>> I agree with all of the small criticisms mentioned below by Radoslaw
>>> except for the renaming of precondition() to require(). I think it is
>>> an improvement that it describes an action now, just like assert().
>> 
>> Interestingly, I was the one that insisted on that change, as I felt
>> “precondition” was too much of a term-of-art and “require” would be more
>> accessible, but I am now regretting that decision.  This function is not
>> conceptually an action; like “assert,” it's a declarative statement, and
>> “precondition” conveyed that aspect much better, IMO.
> 
> How about expect()? Should not have much string attached to it. Only thing coming to mind is the 
> TCL extension used for automation.

That's not bad, but to me "expect" seems more open-ended than "require" or "precondition", i.e. "if it isn't true, then what?". I don't assume that it's going to be fatal.

(It even feels a little like an optimization hint to me, like "expect(self.dynamicType === BaseClass.self)". It could still be a subclass, but the compiler would know what the common case is.)

Jordan


More information about the swift-evolution mailing list