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

[plx]

> On Jan 29, 2016, at 3:03 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Jan 29 2016, Alex Migicovsky <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On Jan 29, 2016, at 8:33 AM, Dave Abrahams via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> on Thu Jan 28 2016, Alex Migicovsky
>> 
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> <mailto: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)?”

If that’s really the intended axis `precondition` is better than `require` or similar.

Another outlook on asserts is essentially that you should classify each potential assertion on two axes:

- semantic importance of checked invariant (e.g. “expected” vs “requirement”)
- performance impact of check (e.g. negligible, moderate overhead, or materially-slower (e.g. O(n) -> O(n^2))

…and then use a suitably-“strong” strength-of-assertion for that setting.

I think at least a few of us have been interpreting the two assertion types along these lines—in spite of the name!—whence the focus on the “what is included in which build types?” behavior.

> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/727c77cb/attachment.html>