Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Joseph Lord via swift-evolution]

> • What is your evaluation of the proposal?

-1

Code churn, new function name has the same issues as the old one. 
Benefits small. It is also likely that those suffering with the String 
collectionifying will have already solved their issues before this 
update could be introduced.


> • Is the problem being addressed significant enough to warrant a 
change to Swift?


No.

> • Does this proposal fit well with the feel and direction of Swift?

Distraction from major directions, little gain.

> • How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?


Read proposal and scanned the discussion so far in this review.

We did actually hit the bug where a String was flatMapped and behaviour 
changed in Swift 4 migration a couple of weeks ago which caused some 
discussion to find out what the issue was but we solved it and there is 
a fair chance the renamed version could equally have had exactly the 
same issue.


Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Joseph Lord via swift-evolution]

> • What is your evaluation of the proposal?

-1

Code churn, new function name has the same issues as the old one. 
Benefits small. It is also likely that those suffering with the String 
collectionifying will have already solved their issues before this 
update could be introduced.


> • Is the problem being addressed significant enough to warrant a 
change to Swift?


No.

> • Does this proposal fit well with the feel and direction of Swift?

Distraction from major directions, little gain.

> • How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?


Read proposal and scanned the discussion so far in this review.

We did actually hit the bug where a String was flatMapped and behaviour 
changed in Swift 4 migration a couple of weeks ago which caused some 
discussion to find out what the issue was but we solved it and there is 
a fair chance the renamed version could equally have had exactly the 
same issue.


Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Joseph Lord via swift-evolution]

+1 I'm sold by Brent's reasoning that sealed is the only way to keep options 
open, both for any given library and for the whole Swift language. I've stayed 
quiet until now because while philosophically inclined to final by default I 
was concerned about potential complexity and confusion.

I haven't read everything on the mailing list but I've read several blog posts 
on both sides.

In terms of the necessity of subclassing it feels to me that subclassing where 
not designed for it is a similar in principle to using private APIs which may 
at times be the only way to achieve certain things but at least on iOS the App 
Store policies prevent that.

I don't have very strong views about the syntax I'm afraid but if this is 
something that could be reversed there should be an explicit version of the 
default sealed case (like internal is with for access controls).

Joseph

On Jul 19, 2016, at 8:43 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution 
>>  wrote:
>> 
>> Denial of subclassing has always been opt-in in ever other language I’ve 
>> used (C++ and Java, to name two, and Objective-C (and older C++) don’t even 
>> have that much). Sealing a class against subclassing is one thing, but not 
>> providing any kind of escape hatch, any kind of 
>> IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, 
>> hamstrings all users of the code. Opt-in sealing at least constrains this 
>> scenario to places where the framework writer thought it was worth adding 
>> the extra protection against horrible horribleness.
> 
> You know, one thing I haven't seen mentioned is that, just as 
> sealed-by-default preserves the options of library programmers, it also 
> preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we 
> ultimately conclude that sealed-by-default is a disaster. What can we do 
> about it? Well, we change Swift 3+n to open all classes by default. This 
> would be source- and binary-compatible with all existing code; the only 
> wrinkle is that classes compiled with a sealed-by-default compiler would 
> still be sealed. (And that's not even a problem yet, since stable ABIs are 
> not a thing yet.)
> 
> The reverse, however, is *not* true. Going from open-by-default to 
> sealed-by-default is source- and binary-incompatible. If we don't do it now, 
> we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; 
> there are good arguments that it will improve things, but there are also good 
> arguments that it will make things worse. But if we're afraid to try this 
> now, we'll never be able to try it again, and we won't know if it would have 
> worked. Whereas if we *do* try it now, we can always roll it back later.
> 
> Software quality is one of the biggest problems our profession faces. We 
> handle crushing amounts of complexity, teetering towers of abstraction, 
> intertwined code that's at the ragged edge of our ability to comprehend it. 
> Quite possibly the most urgent need in our industry is tools to help us 
> manage it.
> 
> Sealed-by-default might turn out to be a powerful tool for managing 
> complexity, helping us prevent unexpected interactions between the 
> implementation details of separate modules. Or it might not. But we ought to 
> find out. If we always take the conservative option, if we always stick to 
> the tried and true, we will never advance the state of the art, never find 
> solutions to the problems that make "all software sucks" a truism.
> 
> We need to be bold and take a chance. If it doesn't work out, we can undo it. 
> But if it does work out, we'll be better for it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

[Joseph Lord via swift-evolution]

On 12/07/2016 19:26, Chris Lattner via swift-evolution wrote:


The review of "SE-0121: Remove `Optional` Comparison Operators" begins now and 
runs through July 19. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md




* What is your evaluation of the proposal?


I approve. I actually filed a (rdar://19366632) in Jan 2015 about this 
behaviour.



* Is the problem being addressed significant enough to warrant a change 
to Swift?


Yes. It can catch out the unwary in several ways and is objectively 
surprising behaviour.



* Does this proposal fit well with the feel and direction of Swift?


Yes.


* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?


Well Swift is the main language with explicit optionals that I have used 
but comparisions with nil/NULL vary in behaviour between languages. In 
SQL for example NULL is taken as unknown and even an equality 
comparision between NULL values fails. It could be worth going as far as 
removing the equality between optionals for this reason (although we 
could still keep the NilLiteralConvertible (or Swift 3 named version) 
for equality checks (I would also be fine with reusing the `is` keyword 
but haven't thought about that deeply. i.e. `if foo is nil {`



* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?



Read proposal and review discussion so far but have also considered it 
in the past and have warned about the behaviour in talks in the past.


Joseph

--
Human Friendly Ltd.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

[Joseph Lord via swift-evolution]

> The review of "SE-0113: Add integral rounding functions to FloatingPoint" 
> begins now and runs through July 5. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md
> 
>* What is your evaluation of the proposal?

It is an improvement but would it be even better if the return type was Int (or 
possibly type inferred to Int16 etc.). If a float is really desired it can be 
initialised from the Int (or it could even infer float result is required). 

>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes, reduces reliance on C APIs. API also clearer about semantics. 

>* Does this proposal fit well with the feel and direction of Swift?

Yes

>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

Quick read and a quick look at earlier discussion linked from proposal. 

Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

[Joseph Lord via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md

 >   * What is your evaluation of the proposal?

Agree.

In extensive Swift use I've never had cause to actively use Boolean 
rather than Bool.


If there is a need to keep it (which I don't see) I think it would be 
better renamed to something less succinct and confusing.



  * Is the problem being addressed significant enough to warrant a
change to Swift?


Yes. Removing things, especially confusing things is good when there is 
little impact.



  * Does this proposal fit well with the feel and direction of Swift?


Yes.


  * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?



Quick read.

Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft Proposal for pre discussion]NS_ENUM's should be considered Open

[Joseph Lord via swift-evolution]

Can I get some thoughts about this idea to remove undefined behaviour 
from switch statements when an enum imported from Objective-C has a raw 
value outside the expected set?


The proposal is on my fork and below: 
https://github.com/josephlord/swift-evolution/blob/master/proposals/-consider_ns_enums_open.md


Thanks,

Joseph

# NS_ENUMs should be considered Open

* Proposal: 
[SE-](https://github.com/josephlord/swift-evolution/blob/master/proposals/-consider_ns_enums_open.md)

* Author(s): [Joseph Lord](https://github.com/josephlord)
* Status: [Early Draft]
* Review manager: TBD

## Introduction

Enums imported from C/Objective C could (as a result of library 
versioning or bugs) actually have raw values outside of the defined 
values. A default case should be required on switch statements involving 
them and the current undefined behaviour should be removed.


Swift-evolution thread: [To be filled in after discussion]

## Motivation

In cases where an enum value is outside of the expected range and there 
is no default in a switch the behaviour is currently undefined (it seems 
to take the first case in practice) potentially leading to runtime 
crashes. Undefined behaviour and crashes at runtime due to library 
changes outside the developer's control are highly undesirable and Swift 
should be helping us to make safe code to prevent them. At the moment if 
you are handling all cases it is not even possible to add a default case.


I encountered the issue when testing on iOS 8 and hitting [an issue with 
CoreData](http://stackoverflow.com/a/32978387/1476206) where it was 
passing a zero value the NSFetchedResultsChangeType to my code. That 
thread clearly shows that the issue is affecting people and while it is 
clearly a bug in the unsafe code of Core Data that is something which 
Swift should be defending against. There is a simple test example 
showing the issue in [SR-1258](https://bugs.swift.org/browse/SR-1258)


## Proposed solution

Redefine NS_ENUMs from being a closed type to an open one. This would 
then require a default case on all switch statements over the type. With 
the default case explicit situation must be handled by the developer. 
They can choose to raise errors call assertionFailure or 
preconditionFailure as the wish or handle the case safely.


## Detailed design

 - Help required here

## Impact on existing code

This will break all switch statements over an enum imported from 
Objective-C or C where there is no default case. There should not be any 
automatic migration because it is appropriate for the developer to 
decide on the course of action in each case.


## Alternatives considered

1) No change

This leaves the potential for undefined behaviour in all build modes if 
cases of bugs in code outside of Swift OR in the event that new cases 
are added to enums in future library versions.


2) Debug assertion

This would have the benefit that developers might discover errors more 
quickly but could still leave risks where libraries (including OS 
frameworks) are updated and introduce bugs after application release or 
in untested configurations.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Joseph Lord via swift-evolution]

On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote:

Hello Swift community,

The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs 
through March 30th. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md



As I don't use IUO optionals I'm really fairly neutral on the proposal. 
I just wanted to mention with the powerful tools we have for dealing 
with optionals (optional, chaining, nil-coalescing, map, flatmap, guard, 
and let - thanks Chris and team) it really would be quite feasible to do 
away with IUOs completely. I don't think the community is ready for that 
yet so I'm not proposing that course of action at this time but such a 
proposal wouldn't get a universally hostile response.


Even force unwrap is something that I only do test code since flatmap 
was added to the Standard Library (I used to have my own implementation 
of flatmap with a force unwrap after a filter which was the only 
production use I've put force unwrap to).


Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

[Joseph Lord via swift-evolution]

> On Mar 24, 2016, at 6:00 PM, Chris Lattner  wrote:
> 
> The review of "Remove explicit use of let from Function Parameters" begins 
> now and runs through March 27th. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md

+1 seems obvious to me. I suspect the syntax is rarely used anyway.

Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

[Joseph Lord via swift-evolution]

> On Mar 22, 2016, at 9:35 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "Adding initializers to Int and UInt to convert from 
> UnsafePointer and UnsafeMutablePointer" begins now and runs through March 
> 25th. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md

I give the concept a +1. Swift should support dangerous actions but should make 
them clear and obvious. I do think that there is room to improve the argument 
label. There are two issues with "bitPattern" that concern me:
1) it should be clear that it will be the bitPattern of the pointer itself not 
whatever the pointer refers to.
2) it doesn't indicate the danger of using the results of this 

I don't have a great alternative to bitPattern but maybe something like: 
"rawMemoryAddress"

I've read the proposal and given it a little bit of thought but have not yet 
read preceding or recent comments. 

Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Joseph Lord via swift-evolution]

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 <clatt...@apple.com> wrote:
>> 
>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution 
>> <swift-evolution@swift.org> 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 never 
>> be called.
> 
> Right.
> 
>> This documented behaviour would allow the compiler to completely eliminate 
>> tests and branches before or after the assertion and take the operation deep 
>> into undefined behaviour.
> 
> Only in cases where the assertion would have failed, right?  The point of 
> -Ounchecked is that - if your code was correct with the checks - that it will 
> still be correct.  Disabling overflow and array bounds checks is far more 
> dangerous than the assertion behavior you cite here.

Yes only when it would have failed but that may still make correct code 
incorrect where whole branches of runtime belt and braces code could be a 
eliminated. 

>> It appears from the code as if the assumption is not currently applied on 
>> the assert method although it is on the assertionFailure case by means of 
>> the _conditionallyUnreachable() call. assert seems to be a no-op in both 
>> normal release and disable safety checks build modes.
> 
> Right.
> 
>> [Proposed Change]
>> 
>> Change the documentation for assert and assertionFailure so that behaviour 
>> in unchecked mode is the same as in normal release - no evaluation and no 
>> effect.
> 
> Why? :
> 
>> 1) Expected behaviour based on other languages is for assert to have no 
>> effect in release. (If current behaviour is highly desired another function 
>> name should be used). Having potential dangerous behaviour from a function 
>> that is familiar across languages and is regarded as a safety feature is 
>> undesirable.
> 
> This is the C model, but as you know, there is a whole field of custom 
> assertions libraries that people have developed.  I don’t think there is 
> anything like consensus on this topic.

C, Python, Erlang, Ocaml, Java (although it can enabled at runtime) and 
probably more. I recognise that in house assertion policies and systems may 
have different behaviours and agreed modes but I think affecting surrounding 
code (before and after the assertion) is surprising based on people experience 
with these other languages. I have not seen elsewhere any instances of 
compilers removing code outside of the branch itself which could be possible if 
the compiler is allowed to assume the truth of the assertion condition. 

if let names = jsonObject as? [String] where names.count > 0 {
  print(names.first)
} else {
  assertionFailure("Invalid JSON")
  return nil
}

Could be compiled to pretty much an unconditional print of an address in 
unchecked. The nil return could be unreachable, the if let reduced to an unsafe 
bitcast (maybe not given array bridging but possibly in other cases) and the 
.first converted to [0] given the assumed passing of the where clause.

>> 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 
>> behaviour.
> 
> This only affects code built with -Ounchecked, which is definitely not a safe 
> mode to build your code.  The intention of this mode is that you can use it 
> to get a performance boost, if you believe your code to be sufficiently 
> tested.  This mode, which isn’t the default in any way, intentionally takes 
> the guard rails off to get better performance.
> 
> If you don’t like that model, don’t use this mode

One fear is that libraries will be compiled in this way by people who aren't 
the original authors and that people won't realise the consequences.

>> 3) "For highly robust code assert and then handle the error anyway" [Code 
>> Complete 2nd Edition section 8.2]
> 
> Highly robust code shouldn’t build with -Ounchecked, so I don’t see how this 
> point is pertinent.

The quote was external validation of the concept of having asserts where the 
case is also handled. I would not limit the use to "highly robust code". 

However as I said in my other email if no one else is concerned I will just go 
away and use my custom assertions and miss out on the compiler hinting.

Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Joseph Lord via swift-evolution]

> On Jan 2, 2016, at 5:39 PM, Dave Abrahams via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution 
>>> <swift-evolution@swift.org> 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 
>>>> never be called.
>>> 
>>> Right.
>>> 
>>>> This documented behaviour would allow the compiler to completely eliminate 
>>>> tests and branches before or after the assertion and take the operation 
>>>> deep into undefined behaviour.
>>> 
>>> Only in cases where the assertion would have failed, right?  The point of 
>>> -Ounchecked is that - if your code was correct with the checks - that it 
>>> will still be correct.  Disabling overflow and array bounds checks is far 
>>> more dangerous than the assertion behavior you cite here.
>>> 
>>>> It appears from the code as if the assumption is not currently applied on 
>>>> the assert method although it is on the assertionFailure case by means of 
>>>> the _conditionallyUnreachable() call. assert seems to be a no-op in both 
>>>> normal release and disable safety checks build modes.
>>> 
>>> Right.
>>> 
>>>> [Proposed Change]
>>>> 
>>>> Change the documentation for assert and assertionFailure so that behaviour 
>>>> in unchecked mode is the same as in normal release - no evaluation and no 
>>>> effect.
>>> 
>>> Why? :
>>> 
>>>> 1) Expected behaviour based on other languages is for assert to have no 
>>>> effect in release. (If current behaviour is highly desired another 
>>>> function name should be used). Having potential dangerous behaviour from a 
>>>> function that is familiar across languages and is regarded as a safety 
>>>> feature is undesirable.
>>> 
>>> This is the C model, but as you know, there is a whole field of custom 
>>> assertions libraries that people have developed.  I don’t think there is 
>>> anything like consensus on this topic.
>>> 
>>>> 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 
>>>> behaviour.
>>> 
>>> This only affects code built with -Ounchecked, which is definitely not a 
>>> safe mode to build your code.  The intention of this mode is that you can 
>>> use it to get a performance boost, if you believe your code to be 
>>> sufficiently tested.  This mode, which isn’t the default in any way, 
>>> intentionally takes the guard rails off to get better performance.
>>> 
>>> If you don’t like that model, don’t use this mode.
>> 
>> Let’s just consider -O; I think I understand Joseph’s objection here, and it 
>> seems valid.
>> 
>> Normally in -O, we say that if you stay in the “safe subset” of Swift code, 
>> you never get undefined behavior, even if there’s a bug in your code.  You 
>> might get *unpredictable* behavior of course, but presumably guaranteeing no 
>> undefined behavior rules out large classes of problems, including many 
>> security holes.  Now suppose you decide to be responsible and add some 
>> asserts to help you catch bugs during development.  Hopefully they help you 
>> catch all the bugs, but what if they don’t?  All of a sudden, if you still 
>> have a bug when you ship, you now have undefined behavior.  As much as I’m a 
>> fan of assertions having optimization benefits, It seems a little perverse 
>> that using them could make shipping code less secure.
> 
> Wait a sec; I just read the doc comments for assert over again.  They don’t 
> say there’s undefined behavior in -O if the condition isn’t satisfied.  So 
> now I don’t understand what Joseph is complaining about.  assert in -O is 
> documented to act exactly as C’s assert would with NDEBUG #defined.
> 
> -Dave

Than

[swift-evolution] Asserts should not cause undefined behaviour

[Joseph Lord via swift-evolution]

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 for setting out my thoughts clearly to trigger the 
discussion but I'm not trying jump the discussion phase. I'm open to 
radical rewrites or to not proceed if there is opposition. Also if my 
understanding of the current code is wrong please let me know.


[Current Situation]

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 never be called.


This documented behaviour would allow the compiler to completely 
eliminate tests and branches before or after the assertion and take the 
operation deep into undefined behaviour.


https://github.com/apple/swift/blob/cf8baedee2b09c9dd2d9c5519bf61629d1f6ebc8/stdlib/public/core/Assert.swift 
(latest commit to this file at time of writing)


[NOTE - Actual current behaviour]

It appears from the code as if the assumption is not currently applied 
on the assert method although it is on the assertionFailure case by 
means of the _conditionallyUnreachable() call. assert seems to be a 
no-op in both normal release and disable safety checks build modes.


It also appears that precondition does not apply the permitted 
assumption when in _isFastAssertConfiguration mode.


There also appears to be code in assert to hint the compiler that the 
assert will likely be true. This was something that I was planning to 
suggest and means that code containing asserts can be faster than the 
same code without the assert in release mode.


[Proposed Change]

Change the documentation for assert and assertionFailure so that 
behaviour in unchecked mode is the same as in normal release - no 
evaluation and no effect.


Change the behaviour of assertionFailure to match the updated documentation.

[Motivation]

1) Expected behaviour based on other languages is for assert to have no 
effect in release. (If current behaviour is highly desired another 
function name should be used). Having potential dangerous behaviour from 
a function that is familiar across languages and is regarded as a safety 
feature is undesirable.


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 behaviour.


3) "For highly robust code assert and then handle the error anyway" 
[Code Complete 2nd Edition section 8.2] While the designed expectation 
from the Swift team is to use them for checks against internal 
programming errors within a module in a number of cases I use assertions 
and assertionFailure calls while processing input data. The code without 
the assertion would simply fail to read the input gracefully but as the 
developer I want to know immediately if there are realistic cases that 
have not been handled so use assertions to flag it to myself that a case 
may need better handling. As such there are assertions in my code that 
are in error cases that I expect not to occur. I do not want the runtime 
safety checks being optimised out. [Being aware of this issue I use 
custom assertions but am therefore missing out on the branch hinting of 
the stdlib version and others may want similar behaviour and may not 
fully read the documentation].


[Impact on existing code]

Loss of performance in cases where assertionFailure is used. Loss of 
potential performance improvement option in assert usage. In most cases 
this performance loss will be small but there is potential where the 
assumption of the value allows large code blocks (to evaluate the 
condition) to be eliminated for significant effects but I suspect that 
these cases are rare and preconditionFailure could be used instead to 
get the performance in unchecked builds (at the cost of release 
performance) or an additional method could be added.


[Alternatives]

Renaming assert so that the behaviour is not assumed by users familiar 
with other languages. Function name suggestion:


assume/assumeUnreachable

This could either behaviour as the current assert/assertionFailure 
documentation or possibly allow the assumption to be made in normal 
release mode not just the unchecked. It should be a fatal error in debug 
builds if assumption is incorrect.


[Note about precondition]

precondition/preconditionFailure also have undefined behaviour in 
unchecked mode but this is not a problem for me for a couple of reasons:


1) I don't have the same prior understanding about what they do.

2) It is clear from release build behaviour that hitting the condition 
is always an error.