[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