I gave a quick reply to an email later in the chain last night but I think
these points are worth addressing. Apologies for the slow response, I wanted to
ponder and consider the points rather than rush the response.
>> On Dec 31, 2015, at 8:27 PM, Chris Lattner wrote:
>>
>> On Dec 28, 2015, a
Sent from my iPhone
> On Jan 2, 2016, at 6:35 PM, Dave Abrahams wrote:
>
>
>> On Jan 2, 2016, at 2:57 AM, Arnold wrote:
>>
>> 'assert' evaluates the condition and aborts only in Odebug builds.
>>
>> 'precondition' evaluates the condition and aborts also in optimized -0
>> builds.
>>
>> A
'assert' evaluates the condition and aborts only in Odebug builds.
'precondition' evaluates the condition and aborts also in optimized -0 builds.
As far as I remember the decision was made to give it this semantics to mimic
C's assert() function.
If an abort is desired in optimized builds one
> On Jan 2, 2016, at 5:39 PM, Dave Abrahams via swift-evolution
> wrote:
>
>
>>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution
>>> wrote:
>>>
>>>
>>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution
>>> wrote:
>>>
>>> On Dec 28, 2015, at 5:48 AM, Joseph L
> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution
> wrote:
>
>>
>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution
>> wrote:
>>
>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution
>> wrote:
>>> The documented behaviour of assert and assertionFail
> On Jan 2, 2016, at 2:57 AM, Arnold wrote:
>
> 'assert' evaluates the condition and aborts only in Odebug builds.
>
> 'precondition' evaluates the condition and aborts also in optimized -0 builds.
>
> As far as I remember the decision was made to give it this semantics to
> mimic C's assert
On Fri, Jan 1, 2016, at 11:58 PM, Kevin Ballard wrote:
> On Fri, Jan 1, 2016, at 11:25 PM, Chris Lattner via swift-evolution wrote:
> > > On Dec 31, 2015, at 1:56 PM, Dave Abrahams wrote:
> > >>> 2) Adding asserts to code should not make the code more dangerous
> > >>> whatever the build. Assumin
On Fri, Jan 1, 2016, at 11:25 PM, Chris Lattner via swift-evolution wrote:
> > On Dec 31, 2015, at 1:56 PM, Dave Abrahams wrote:
> >>> 2) Adding asserts to code should not make the code more dangerous
> >>> whatever the build. Assuming the truth of the assert may lead to runtime
> >>> safety che
> On Jan 1, 2016, at 11:25 PM, Chris Lattner wrote:
>
>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams wrote:
2) Adding asserts to code should not make the code more dangerous whatever
the build. Assuming the truth of the assert may lead to runtime safety
checks being skipped and
> On Dec 31, 2015, at 1:56 PM, Dave Abrahams wrote:
>>> 2) Adding asserts to code should not make the code more dangerous whatever
>>> the build. Assuming the truth of the assert may lead to runtime safety
>>> checks being skipped and undefined behaviour when a no-op would be a safe
>>> behavio
> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution
> wrote:
>
> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution
> wrote:
>> The documented behaviour of assert and assertionFailure in "disable safety
>> checks" builds (still documented as -Ounchecked) is that the c
On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution
wrote:
> The documented behaviour of assert and assertionFailure in "disable safety
> checks" builds (still documented as -Ounchecked) is that the compiler "may
> assume that it would evaluate to true" or in the assertionFailure case
I propose that assert and assertionFailure should be no-ops (with branch
hints) in unchecked builds as they are in normal release builds rather
than resulting in undefined behaviour in the failure condition.
I would like to kick off a discussion of this. I found the proposal
template useful fo
13 matches
Mail list logo
