[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library
migi at apple.com
Thu Jan 28 22:03:19 CST 2016
> On Jan 27, 2016, at 3:33 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.)
Someone I spoke with had a good idea about this IMO. They recommended we have debugAssert and releaseAssert (or debugRequire and releaseRequire). I think this makes the semantics obvious and has consistent terminology between the functions. There’s no question at the call site what was intended.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution