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

[plx]

> On Jan 28, 2016, at 10:03 PM, Alex Migicovsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jan 27, 2016, at 3:33 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jan 26, 2016, at 18:06, Dany St-Amant via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> Le 26 janv. 2016 à 19:39, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>> 
>>>> 
>>>> on Tue Jan 26 2016, Charles Kissinger <swift-evolution at swift.org <mailto: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.

I think something like this is ideal as well, but the names should be something like:

- debugAssert (for today’s assert)
- assert (for today’s precondition)

…since arguably using `debugAssert` and `releaseAssert` is misleading (a `releaseAssert` is included in both debug-and-release).

It seems like something of a migration nightmare to map the `assert` => `debugAssert` and `precondition` => `assert`, but at least it’d match the semantics (and you could change the `assert` base to `require` or `enforce` or `expect`, etc., if you wanted).

I do think `precondition` has been a poor naming choice, because there’s nothing in its name that hints at its semantics in Swift (as an assert active even in release conditions), and guessing the meaning isn’t any easier regardless of whether

- you know its term-of-art use (which arguably says nothing about its relative “strength” vis-a-vis assert)
- you look at the word’s structure (which seems to suggest it most be placed @ the start of a function or method)

…but I don’t think moving to e.g. assert-vs-require really does the needle very far, b/c you’re still in a bit of a mystery-meat scenario if you don’t already know the difference between the two.

> 
> - Alex
> _______________________________________________
> 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/196e8d18/attachment.html>