On Dec 14, 2015, at 5:48 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:
Here’s some rationale that may be missing. The two functions have distinct roles:
- assert: checking your own code for internal errors.
- precondition: for checking that your clients have given you valid arguments.
Makes sense.
I think the issue here is that for many people who write just plain apps, the following holds true:
1) assert performance is not a concern
2) asserts are used to prevent something terrible from happening
3) the most interesting bugs happen inside the code (where assert is appropriate), not on module/layer/class boundaries
Given #1 and #2, we'd prefer to be able to write asserts that can guarantee that the asserted condition never happens below the assertion point.
Why not distinguish between them via assert? and assert!, with "assert?" highlighting the fact that execution may continue in some cases, and "assert!" highlighting the fact that it will always crash?
That would be beneficial when reading other people's code, because it'll show whether they assume that the subsequent code doesn't need to deal with the asserted condition.
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.
···
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com wrote:
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
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.
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.
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
···
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
I’m not so sure, but I don’t have strong feelings about that one. Precondition, however, should IMO remain as it is, observing Dave Abrahams’ arguments and my own above.
-Sune
···
On 15 Dec 2015, at 00:13, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com wrote:
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.
On Dec 15, 2015, at 5:01 AM, Amir Michail <a.michail@me.com> wrote:
What about these renamings?
assert => debugAssert
precondition => assert
On Dec 14, 2015, at 5:48 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:
Here’s some rationale that may be missing. The two functions have distinct roles:
- assert: checking your own code for internal errors.
- precondition: for checking that your clients have given you valid arguments.
Makes sense.
I think the issue here is that for many people who write just plain apps, the following holds true:
1) assert performance is not a concern
2) asserts are used to prevent something terrible from happening
3) the most interesting bugs happen inside the code (where assert is appropriate), not on module/layer/class boundaries
Given #1 and #2, we'd prefer to be able to write asserts that can guarantee that the asserted condition never happens below the assertion point.
Why not distinguish between them via assert? and assert!, with "assert?" highlighting the fact that execution may continue in some cases, and "assert!" highlighting the fact that it will always crash?
That would be beneficial when reading other people's code, because it'll show whether they assume that the subsequent code doesn't need to deal with the asserted condition.
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.
So what you need is just a way to tell the compiler to keep the asserts in optimized builds (if there is not already one).
···
Le 15 déc. 2015 à 00:13, Amir Michail via swift-evolution <swift-evolution@swift.org> a écrit :
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com wrote:
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
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.
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@swift.org> w dniu 15.12.2015, o godz. 00:13:
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com wrote:
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@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.
I think so since ? and ! typically mean something different in Swift.
···
On Dec 14, 2015, at 6:01 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:
On Dec 15, 2015, at 5:01 AM, Amir Michail <a.michail@me.com> wrote:
What about these renamings?
assert => debugAssert
precondition => assert
On Dec 14, 2015, at 5:48 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:
Here’s some rationale that may be missing. The two functions have distinct roles:
- assert: checking your own code for internal errors.
- precondition: for checking that your clients have given you valid arguments.
Makes sense.
I think the issue here is that for many people who write just plain apps, the following holds true:
1) assert performance is not a concern
2) asserts are used to prevent something terrible from happening
3) the most interesting bugs happen inside the code (where assert is appropriate), not on module/layer/class boundaries
Given #1 and #2, we'd prefer to be able to write asserts that can guarantee that the asserted condition never happens below the assertion point.
Why not distinguish between them via assert? and assert!, with "assert?" highlighting the fact that execution may continue in some cases, and "assert!" highlighting the fact that it will always crash?
That would be beneficial when reading other people's code, because it'll show whether they assume that the subsequent code doesn't need to deal with the asserted condition.
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.
max
···
On Dec 16, 2015, at 1:06 AM, Adrian Kashivskyy via swift-evolution <swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> w dniu 15.12.2015, o godz. 00:13:
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com <mailto:sune.foldager@me.com> wrote:
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.
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.
···
On Dec 16, 2015, at 3:19 PM, Max Moiseev <moiseev@apple.com> wrote:
max
On Dec 16, 2015, at 1:06 AM, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> w dniu 15.12.2015, o godz. 00:13:
On Dec 14, 2015, at 6:09 PM, sune.foldager@me.com <mailto:sune.foldager@me.com> wrote:
On 15 Dec 2015, at 00:01, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.
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
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@swift.org <mailto:swift-evolution@swift.org>> w dniu 15.12.2015, o godz. 00:13:
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.