[swift-evolution] Proposal: remove "assert" and always use "precondition" instead.

Dave Abrahams dabrahams at apple.com
Thu Dec 17 01:31:00 CST 2015


> On Dec 16, 2015, at 12:37 PM, Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 16, 2015, at 3:19 PM, Max Moiseev <moiseev at apple.com <mailto:moiseev at apple.com>> wrote:
>> 
>> I’m late for the discussion, sorry.
>> Not answering any particular question here, but FWIW, there is an ongoing effort to apply API naming guidelines to standard library (see the swift-3-api-guidelines branch on github <https://github.com/apple/swift/tree/swift-3-api-guidelines>).
>> One part of that work is: renaming `precodition` to `require`. which, arguably, makes the use-case more clear.
>> 
> 
> I don’t agree with the use case though. I would like to use it for internal checks and keep those checks in the release builds. So the name is misleading for that purpose.

Yep; you want to keep your internal checks distinct for self-documentation purposes if nothing else.  You can easily write your own assert() that is never disabled, though.

> 
>> max
>> 
>>> On Dec 16, 2015, at 1:06 AM, Adrian Kashivskyy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> I want ALL my asserts to be active in release code.
>>> 
>>> What's the problem in using `precondition` then?
>>> 
>>> Pozdrawiam – Regards,
>>> Adrian Kashivskyy
>>> 
>>>> Wiadomość napisana przez Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> w dniu 15.12.2015, o godz. 00:13:
>>>> 
>>>> 
>>>>> On Dec 14, 2015, at 6:09 PM, sune.foldager at me.com <mailto:sune.foldager at me.com> wrote:
>>>>> 
>>>>> 
>>>>>> On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> What about these renamings?
>>>>>> 
>>>>>> assert => debugAssert
>>>>>> 
>>>>>> precondition => assert
>>>>> 
>>>>> I think precondition is a better name because it clearly expresses that this is an expected precondition for calling the method. Precondition is similar to Microsoft code contract’s Contract.Requires.
>>>> 
>>>> I want ALL my asserts to be active in release code. Correctness is more important than performance for me. I suspect this is also the case with most programmers.
>>>> 
>>>>> 
>>>>> Also, the traditional use of assert (also in other languages) is for guarding against your own programmer errors, which I think most people expect when they see assert. It may be useful for an assert that’s still active in optimised builds, true. I guess that could be called assert! or assertAlways.
>>>>> 
>>>>> -Sune
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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>
>>> 
>>> _______________________________________________
>>> 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>
>> 
> 
>  _______________________________________________
> 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>
-Dave



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/008f25f5/attachment.html>


More information about the swift-evolution mailing list