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

[Alex Migicovsky]

> 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 :-)

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