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

[Dave Abrahams]

on Thu Jan 28 2016, Alex Migicovsky <swift-evolution at swift.org> wrote:

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

Here's the problem with that suggestion: these things really have
completely different purposes; we don't want them to lose the semantic
distinction that "this is a sanity check (assert)" and "this is checking
whether my client is breaking his contract (precondition)."  

-- 
-Dave