<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m late for the discussion, sorry.<div class="">Not answering any particular question here, but FWIW, there is an ongoing effort to apply API naming guidelines to standard library (see the <a href="https://github.com/apple/swift/tree/swift-3-api-guidelines" class="">swift-3-api-guidelines branch on github</a>).<div class="">One part of that work is: renaming `precodition` to `require`. which, arguably, makes the use-case more clear.</div><div class=""><br class=""></div><div class="">max</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 16, 2015, at 1:06 AM, Adrian Kashivskyy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">I want ALL my asserts to be active in release code.</blockquote><br class=""></div>What's the problem in using `precondition` then?<br class=""><div class="">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><font color="#929292" class=""><br class="Apple-interchange-newline">Pozdrawiam – Regards,</font></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><font color="#929292" class="">Adrian Kashivskyy</font></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Wiadomość napisana przez Amir Michail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> w dniu 15.12.2015, o godz. 00:13:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Dec 14, 2015, at 6:09 PM, <a href="mailto:sune.foldager@me.com" class="">sune.foldager@me.com</a> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">What about these renamings?<br class=""><br class="">assert => debugAssert<br class=""><br class="">precondition => assert<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class=""><blockquote type="cite" class=""><br class="">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.<br class=""><br class="">-Sune<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZdiBPeKLcE1ZkxjSogRct0bur3WJrrZggvfZYd5wkdIKOAgIFyzSiZd1kZSqNALmd-2BeCzJ8YfjVVy5pP5-2Fth2l2ltu0-2B37nXRKJ2s0YD9hJCghUEM-2F5a3dqtzMeLSacTGpn-2FIu2dredRZxfCBArKoUqvd8xh4hQi-2F56Ajit3YuEmiPBSO2BKTsbwRnpWSNdOdnCfZs-2BKeiWCCk-2BOMEZJkTXW6eHgh5SGLejFHYAy-2B-2F8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>