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

[Alex Migicovsky]

> 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.

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