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

[Dave Abrahams]

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

>> On Jan 29, 2016, at 8:33 AM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Thu Jan 28 2016, Alex Migicovsky
>
>> <swift-evolution at swift.org
>> <mailto: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).”  
>
> I think that naming convention works fine as long as you think about
> the behavior as tied to how the module that contains that code is
> compiled, right? If you use debugAssert in a module that compiles as
> debug, then that assert will be checked. If you use releaseAssert, it
> will be checked in both release and debug. Maybe I’m missing something
> here though...
>
> One thing I’d really like to improve about the current naming is
> making it obvious at the call site what the behavior of the function
> is. I find that with the current names it’s just a memorization
> game—and I’m not good at memorization :-)

You're not supposed to think about the behavior when you use it.  You're
supposed to ask, "am I checking to make sure that I haven't messed up
(e.g. broken invariants), or that my client hasn't messed up
(precondition violation)?"

-- 
-Dave