Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Philippe Hausler via swift-evolution]

> On Nov 29, 2017, at 2:07 PM, Riley Testut  wrote:
> 
> 
>> On Nov 9, 2017, at 9:01 AM, Philippe Hausler > > wrote:
>> 
>> I have personally filed a few bugs on this; and I definitely consider it a 
>> bug that we cannot store Any in generics for objc. There are however some 
>> problem areas that might be worth considering while fixing this bug. 
>> 
>> 1) We need to ensure this does not cause source churn - I would expect swift 
>> 4 to be source compatible with swift 5.
> 
> Agreed. I'd be surprised if this would cause churn though, since this is 
> effectively just loosening a restriction, and all existing use cases would 
> still be allowed.
> 
>> 
>> 2) There are a few cases that might be a bit cagey - you claim NSCache, but 
>> would it be surprising that the boxed object having no refs gets purged? How 
>> bout NSPointerArray? 
> 
> I agree there are certain cases where true reference semantics are important, 
> and off the top of my head I can think of two (relatively easy) ways we could 
> accommodate this:
> 
> 1) The Objective-C class declaration explicitly specifies an upper-bound of 
> NSObject (or NSObjectProtocol).
> 2) Add a new keyword (similar to existing __covariant and __contravariant 
> keywords) such as __reference (where the final name would of course be 
> bike-shedded)
> 
> I’m leaning towards an approach similar to 2) since 1) might be confusing to 
> newcomers due to it seemingly have no purpose considering the NSObject 
> constraint would implicitly there where using the generic class from 
> Objective-C code.

Option 2 may take a lot of effort just as a heads up since that will mean that 
we would need to audit the entire macOS, iOS, tvOS, and watchOS SDKs and find 
any edge cases (my guess is very very few and perhaps only Foundation)

> 
> I’m not familiar with NSCache’s internals, so I wasn’t aware references play 
> a role in whether or not NSCache purges an object. That being said, I don’t 
> think it would be surprising if NSCache purged a large Data value under 
> memory pressure, as long as it didn’t affect any “copies” I had retrieved and 
> was currently using. 
> 
> As for NSPointerArray, we’d still need to get Objective-C generics for it 
> first  Though assuming that is added, the generic parameter would need to 
> explicitly say it requires a reference.

NSMapTable or NSHashTable might be better examples; if the key or value is 
weakly stored the translated reference will drop off if the held structure is 
mutated.
e.g.

var m = NSMapTable(keyOptions: [.copyIn, .objectPersonality], 
valueOptions: [.weakMemory, .objectPersonality])

var key = "hello" as NSString
var value = Data(bytes: [0, 1, 2, 3]) as NSData

m.setObject(value, forKey: key)

assert(m.object(forKey: key) != nil)

That works as expected - so lets change it to a structure

var m = NSMapTable(keyOptions: [.copyIn, .objectPersonality], 
valueOptions: [.weakMemory, .objectPersonality])

var key = "hello"
var value = Data(bytes: [0, 1, 2, 3])

m.setObject(value, forKey: key) // after here there are no more references to 
value so it is destroyed

assert(m.object(forKey: key) != nil) // this now fails

In that second example even if you had a usage of value past the setObject 
method call that was a mutation it would also fail the assert because the 
backing reference would have changed.

I guess what I am saying is there are edge cases that we have to be careful 
with.

> 
>> 3) Since Foundation is likely the most impact here I think it would be 
>> useful to audit the results of this before pushing it out; specifically the 
>> Foundation internal builds so that we can make sure the things we are 
>> working on function correctly.
>> 
>> Do you have implementations in the works yet? I really think this is 
>> important for us to get in (especially before the ABI gets locked down cause 
>> it could have impact there…)
> 
> 
> No I don’t, but would be open to digging into it and seeing what I could do 
> as a proof-of-concept (I just don’t know where I’d start looking to 
> accomplish this).


Dont get me wrong; I think this is a great idea and vastly improves the state 
of affairs – imho it is very well worth doing and getting this done before we 
cannot change it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Philippe Hausler via swift-evolution]

I have personally filed a few bugs on this; and I definitely consider it a bug 
that we cannot store Any in generics for objc. There are however some problem 
areas that might be worth considering while fixing this bug. 

1) We need to ensure this does not cause source churn - I would expect swift 4 
to be source compatible with swift 5.

2) There are a few cases that might be a bit cagey - you claim NSCache, but 
would it be surprising that the boxed object having no refs gets purged? How 
bout NSPointerArray? 

3) Since Foundation is likely the most impact here I think it would be useful 
to audit the results of this before pushing it out; specifically the Foundation 
internal builds so that we can make sure the things we are working on function 
correctly.

Do you have implementations in the works yet? I really think this is important 
for us to get in (especially before the ABI gets locked down cause it could 
have impact there…)

> On Nov 8, 2017, at 11:49 AM, Riley Testut via swift-evolution 
>  wrote:
> 
> Hi Swift-Evolution,
> 
> Back when SE-0057 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md
>  
> )
>  was proposed, it included the following passage:
> 
> The generic type parameters in Swift will always be class-bound, i.e., the 
> generic class will have the requirement T : AnyObject.
> This made sense at the time, since Swift <-> Objective-C interoperability was 
> only possible with class types (AnyObject). However, several months after 
> SE-0057 was accepted, SE-0116 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
>  
> )
>  was accepted, which allowed for bridging any type to Objective-C, not just 
> class types.
> 
> This greatly improved interoperability between Swift and Objective-C code, 
> but the AnyObject restriction on Objective-C generics remained. This issue is 
> especially apparent when using lesser-known Objective-C collection types such 
> as NSCache, where it may make sense to store value types or use value types 
> as the keys, but the compiler does not allow it.
> 
> I propose that this restriction is lifted, and that generic Objective-C 
> parameters are no longer restricted to conforming to AnyObject. I’m assuming 
> this is not as straightforward as it might seem at first to implement, but I 
> think the benefits would make the effort worth it, since this seems like an 
> overlooked case and not intentionally kept this way.
> 
> Thoughts?
> ___
> 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] Pitch: Member lookup on String should not find members of NSString

[Philippe Hausler via swift-evolution]

I think any serious proposal with the removal of APIs would need to consider 
source compatibility and to do so you should likely audit the API surface area 
that is being offered (and replace it via the NSStringAPI.swift extension)

> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Perhaps you could write up a proposal to outline the missing functionality :-)
> 
> Slava
> 
>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
>> 
>> I would feel better about it if String gained a lot of the utility of 
>> NSString (so that we don’t have to go to NSString all the time for methods)
>> 
>> Thanks,
>> Jon
>> 
>>> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Members of NSString, except those defined in Foundation, are available on 
>>> values of type String. For example,
>>> 
>>> extension NSString {
>>> @objc func foo() {}
>>> }
>>> 
>>> let s: String = “hello”
>>> 
>>> s.foo()
>>> 
>>> We don’t do this for any other bridged types, for instance NSArray methods 
>>> are not imported as Array methods. It’s literally a special case in the 
>>> type checker for member lookup on String.
>>> 
>>> This behavior doesn’t really much sense conceptually and it was put in as a 
>>> stop-gap in Swift 1 to beef up the String API. I would like to phase it out 
>>> as follows:
>>> 
>>> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as 
>>> NSString’ cast
>>> - Error in Swift 5 with -swift-version 5
>>> 
>>> What does everyone think about this?
>>> 
>>> Slava
>>> ___
>>> 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

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

Re: [swift-evolution] Different types for getter and setter

[Philippe Hausler via swift-evolution]

There is another case to consider; similar to nil-resettable. Optional only by 
virtue of never being set, but setting nil values is invalid (e.g. 
Process.environment)

> On Sep 19, 2017, at 9:34 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> There have been a couple times where I've wanted something like this:
> 
> 1) A nil-resettable property without having to resort to making it an IUO. It 
> would be nice to have the setter able to take a T? but the getter return T, 
> and the setter would provide a default value in the event that it receives 
> nil.
> 
> 2) Once I was writing an API that would keep an array of things in a 
> property, but I also wanted a shorthand version where the user could set it 
> with a single value and have the setter transform that into the array 
> internally. Looking back though, that's not really defensible; it's easy 
> enough for the call site to just add two characters and write "foo.property = 
> [x]", and I probably wouldn't stand by that example today.
> 
> 
> On Tue, Sep 19, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution 
> > wrote:
> This may sound rather strange in the abstract, but recently I have 
> encountered two situations where I would like to have a setter that accepts a 
> different type than the getter returns.
> 
> In the first, the getter returns Foo and the setter should accept “@escaping 
> @autoclosure () -> Foo”, so that the expression assigned to the property is 
> not evaluated until it is needed. (The closure is stored in a private 
> property, which the getter evaluates then caches the result.)
> 
> In the second, I want a subscript whose getter returns a concrete type (in my 
> case, subscripting a matrix by row returns an ArraySlice) while the 
> setter can accept something more generic (any kind of Collection with the 
> correct Element type).
> 
> Thoughts?
> 
> Nevin
> ___
> 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

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

Re: [swift-evolution] pitch: Unified libc import (again)

[Philippe Hausler via swift-evolution]

> On Aug 18, 2017, at 5:42 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift  > wrote:
> 
> 
> On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu  > wrote:
> On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker  > wrote:
> 
>> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift > > wrote:
>> I don’t think the “is this library functionality or standard library 
>> functionality” argument is worth having, but if stdout and stdin are 
>> first-class citizens in the Swift world, so should stderr.
>> 
>> As for bringing Foundation into the discussion, you can’t really talk about 
>> Foundation without also talking about the mountains of problems that come 
>> with the monolith pattern. But that’s a completely different conversation to 
>> be had.
>> 
>> I'm not sure what you're getting at here, but I don't believe you've 
>> addressed my question, which is: it's been firmly decided that I/O belongs 
>> in Foundation, and Foundation does in fact offer such facilities--what is 
>> missing from those facilities, and how can we fill it out?
> 
> Lots of I/O functionality is missing from Foundation. Foundation's design 
> from time immemorial is that generally only relatively simple and high-level 
> operations are available in Foundation itself, and if you want to do 
> complicated or non-portable things then you are expected to drop down to 
> POSIX or other C interfaces. That design works less well in Swift than it did 
> in Objective-C because Swift's interface with C, especially low-level C, is 
> often ugly.
> 
> Simple example: there is no way to access file information directly via 
> NSFileHandle. You need to call NSFileHandle.fileDescriptor and pass that to  
> fstat() or fcntl(). The NSFileHandle API in general is sparse and wholly 
> inadequate for sophisticated I/O.
> 
> So that's a good starting point for the discussion.
> 
> What, in your opinion, should be the way forward in addressing this 
> situation? Is there a realistic chance of writing a single comprehensive, 
> cross-platform API that makes possible currently "complicated or non-portable 
> things" on both macOS/iOS/tvOS/watchOS and Linux, and potentially Windows? If 
> so, does that fit within the general category of filling out the currently 
> sparse Foundation APIs or would that be a matter for a separate library? In 
> the alternative, is it the right solution to make dropping down to POSIX 
> marginally easier by re-exporting C APIs under a unified name, without 
> attempting a single cross-platform API?
> 
> 
> 
> For what it’s worth, CoreFoundation appears to support windows environments, 
> at least for things like path manipulation. However atm it’s not very 
> relevant as Swift doesn’t run on Windows rn.
> 
> If I recall, the CoreFoundation code for Windows is from a long-abandoned 
> port that no longer works, to the point that it is thought unsuitable as a 
> basis for a modern port.


I don’t think abandoned is the right term per-se. But the branch of 
CoreFoundation that is used for the CF inside of swift-corelibs-foundation has 
moved in a different direction than the one being used for the Windows support 
(might be better to think of it as a fork that diverged). I would definitely 
agree that anything of an update for windows support should definitely reach 
out and work together to see what we can and should update. But as it stands - 
I don’t think that is fully operational at the current point in time (modulo 
perhaps Cygwin; which recently had some contributors working on that front).

If a contributor wants to revitalize the windows portion I would be very 
willing to aide in that endeavor.

> ___
> 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] [Concurrency] async/await + actors

[Philippe Hausler via swift-evolution]

I have read over the proposal and already asked a few questions ahead of the 
email chain and I have some follow up points that are perhaps worth 
consideration.

First off, I think that async/await is a great concept! From personally using a 
similar concept in C#, I think it can be an approachable yet powerful tool to 
resolve a decent number of problems with threading. It is worth stating, 
however, that it does NOT solve all problems with threading, or at least, not 
on its own.

One thing I have in mind is that Swift, of course, does exist in a vacuum. It, 
by nature, is being used for writing iOS, watchOS and macOS applications to be 
shipped on those platforms. On those platforms, libdispatch is often used for 
things like completion handlers and similar (or indirectly used via 
NSOperationQueue). Of course there are a few of those devices that only have 
one core or are thermally constrained under load. It is then imperative that 
applications (at least under the hood) utilize appropriate quality of service 
to ensure that certain workloads do not get scheduled as much as others. For 
example: if an application is synchronizing some sort of state over the 
network, it may be the best choice to run that work at a low 
quality-of-service. In this example, if a specific piece of work is then 
blocked by the work that is running at a low quality-of-service, it needs to 
temporarily override that low quality-of-service to match the blocked work. I 
think that any concurrency model we consider should be able to work 
constructively with a situation like this, and take QoS into account.

For sake of argument, though: let's presume that completion handlers are always 
going to be appropriately scheduled for their quality-of-service. So why is the 
override important to think about? Well... in the cases of single core, or 
other cases where a ton of work in limiting the number of cores available, 
there can be a problem known as a priority inversion. If no override is made, 
the low priority work can be starved by the scheduling of a waiter. This 
results in a deadlock. Now you might of course think: "oh hey, that's 
DispatchSemaphore's responsibility, or pthread_condition_t" etc... 
Unfortunately semaphores or conditions do not have the appropriate information 
to convey this. To offer a solution to this problem, the start of the 
asynchronous work needs to be recorded for the threads involved to the end of 
that asynchronous work, then at the beginning of the waiting section an 
override needs to be created against those asynchronous threads and the 
override is ended at the point that it is done waiting.

In short, effectively just waiting on completion handler will cause severe 
performance problems - to resolve this it seems like we absolutely need to have 
more entry points to do the correct promotions of QoS. 

What do you think is the best way of approaching a resolution for this 
potential pitfall?

> On Aug 17, 2017, at 3:24 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> As Ted mentioned in his email, it is great to finally kick off discussions 
> for what concurrency should look like in Swift.  This will surely be an epic 
> multi-year journey, but it is more important to find the right design than to 
> get there fast.
> 
> I’ve been advocating for a specific model involving async/await and actors 
> for many years now.  Handwaving only goes so far, so some folks asked me to 
> write them down to make the discussion more helpful and concrete.  While I 
> hope these ideas help push the discussion on concurrency forward, this isn’t 
> in any way meant to cut off other directions: in fact I hope it helps give 
> proponents of other designs a model to follow: a discussion giving extensive 
> rationale, combined with the long term story arc to show that the features 
> fit together.
> 
> Anyway, here is the document, I hope it is useful, and I’d love to hear 
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
> 
> -Chris
> 
> ___
> 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] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

[Philippe Hausler via swift-evolution]

> On Jul 14, 2017, at 1:40 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jul 14, 2017, at 4:31 PM, Charles Srstka > > wrote:
>>> On Jul 14, 2017, at 3:24 PM, John McCall >> > wrote:
>>> 
>>> We should absolutely not need to do the later autoreleases.  We have logic 
>>> to autorelease objects when calling returns-inner-pointer objects on them, 
>>> but we shouldn't need to do that in safe patterns like what Data does here 
>>> by scoping the pointer to the closure.  We probably just don't actually 
>>> have a way to turn that logic off, i.e. an equivalent of 
>>> objc_precise_lifetime in ObjC ARC.
>>> 
>>> I have no idea why the first autorelease wouldn't be reclaimed.  There's a 
>>> well-known issue with micro-reductions involving autoreleases on x86, where 
>>> the first autorelease from the executable doesn't get reclaimed because the 
>>> dynamic linker's lazy-binding stub interferes somehow.  Can you verify that 
>>> you still see that initial autorelease on subsequent Data creations?
>> 
>> Changing the loop to run five times, I end up with five NSConcreteDatas in 
>> Instruments. For the first one, I get the initial autorelease in 
>> -[NSConcreteFileHandle readDataOfLength], as well as the subsequent 32,768 
>> autoreleases (it actually seems to be one autorelease per every 32 bytes in 
>> the data; if I adjust the buffer size the number of autoreleases changes 
>> accordingly). 
>> 
>> For the other four… it looks exactly the same, actually. :-/
>> 
>> Instruments .trace file is available off-list by request.
> 
> Would you mind just filing a bug with a reduced test case?
> 
> John.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Would it perhaps be reasonable for the Data backing to manually managed the 
storage via Unmanaged? Since we know the lifespan of the container and are the 
sole controllers in most places.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

[Philippe Hausler via swift-evolution]

> On Jul 12, 2017, at 3:23 AM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> Hello, swift community!
> 
> Recently I’ve come across a dilemma regarding value-type semantics when 
> dealing with generic types.
> Consider a protocol that has a mutating in-place function and a non-mutating 
> returning variant of that function:
> 
> protocol Transmogrifier {
> 
> mutating func transmogrify()
> 
> func transmogrified() -> Self
> 
> }
> 
> One of these methods has to have a default implementation in terms of the 
> other.
> 
> One way doing it is to implement the mutating version in terms of 
> non-mutating because it doesn’t depend on additional conditions to work, 
> since assigning to `self` causes a complete copy of the internal state of the 
> object regardless of whether it’s a value type or a reference type. However, 
> this approach has a big downside: in many cases mutating functions mutate 
> only part of the instance, which means that an efficient implementation will 
> have to implement the mutating version and because of the way the default 
> implementation works, the non-mutating version would also need to be manually 
> implemented, which makes the default implementation useless in those cases.
> 
> Implementing the non-mutating version in terms of mutating version solves 
> this problem nicely, allowing one to focus on mutating only the necessary 
> parts of the instance, while leaving the need to return a separate instance 
> to the default implementation, which would be perfectly adequate in most 
> cases. This approach has its own problem that this pitch seeks to solve. The 
> problem becomes apparent when you consider this naive implementation:
> 
> extension Transmogrifier {
> 
> public func transmogrified() -> Self {
> var result = self
>   result.transmogrify()
>   return result
> }
> 
> }
> 
> The above implementation is only correct for value types, because assignment 
> is a deep copy. If the instance is of a reference type, the assignment will 
> do nothing and the call to the mutating version will apply to the original 
> object, violating the postcondition of the function (which states that the 
> function shall not modify the instance in any way).
> 
> The most straight-forward way of solving this problem is to introduce a new 
> protocol for making sure the original instance is always copied:

Immutable types like NSString, NSDictionary etc just return self for the copy.

> 
> protocol CopyInitializable {
> 
> init(copying other: Self)
> 
> }
> 
> In which case the default implementation becomes fully correct:
> 
> // The `CopyInitializable` conformance can also be moved to the protocol 
> itself
> // if the protocol conformance requires value-type semantics.
> extension Transmogrifier where Self: CopyInitializable {
> 
> public func transmogrified() -> Self {
> var result = Self(copying: self)
>   result.transmogrify()
>   return result
> }
> 
> }
> 
> The downside of this approach is the need to manage CopyInitializable 
> conformance of the types  that becomes extra hassle that seems to conflict 
> with the behavior of value types.
> 
> This pitch proposes adding CopyInitializable protocol to the swift standard 
> library and having the compiler automatically generate conformance to it for 
> all value types.
> This would immediately solve all problems of correct convenient 
> implementations of non-mutaiting variants of in-place functions as well as 
> remove the hassle of having to manage conformance to CopyInitializable for 
> all value types that are guaranteed to have this behavior in the first place.
> 
> An good use case would be the NSNumber class, which would conform to 
> CopyInitializable and make use of a single obvious mutating-to-nonmutating 
> implementation of arithmetic operations that would work equally well on all 
> standard numeric types.


NSNumber is an immutable reference type, so copy just returns a strong 
reference to itself. So how would a copy initialization of a NSNumber add any 
value? If we were to add a copy initializer to NSNumber, it would probably be 
implemented as just replacing self in the init with the other object.

For reference types there is already a protocol for what you are attempting to 
do; NSCopying (granted it probably should have a Self return instead of Any… 
but that is a different can-o-worms).

> 
> I’d like to hear opinions regarding this pitch and in case of consensus, I’d 
> write an official proposal and offer it for review.
> 
> Regards,
> Gor Gyolchanyan.
> 
> ___
> 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] [Pitch] Introducing role keywords to reduce hard-to-find bugs

[Philippe Hausler via swift-evolution]

I too really like this proposal; personally I can attest to how it probably 
would have saved some time and headache with the Foundation overlay as well as 
swift-corelibs-foundation (specifically when adopting Collection and friends 
for types)

Would it be reasonable to have this apply to typealiases as well? Or does not 
only make sense for functions/properties etc?

I presume this would also be something exposed in the interfaces when viewing 
APIs?

Does this perhaps have any objc protocol interaction? (e.g. do we need an 
attribute to adopt things? Or perhaps can we leverage this to address the 
disparity 'tween objc protocols and swift protocols for optional methods via 
this same mechanism?)

> On Jun 14, 2017, at 10:46 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 14 2017, Chris Lattner  > wrote:
> 
>>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution
>>>  wrote:
>>> 
>>> Some pals and I have been kicking an idea around about introducing
>>> better ways to support the compiler in protocol extensions. We want
>> 
>>> to eliminate some hard-to-detect bugs. We've been brainstorming on
>>> how to do this without affecting backward compatibility and
>>> introducing a minimal impact on keywords.
>>> 
>>> We'd love to know what you think of our idea, which is to introduce
>>> "role" keywords. Roles allow the compiler to automatically check the
>>> intended use of a extension member definition against its protocol
>>> declarations, and emit errors, warnings, and fixits as needed.  We
>>> think it's a pretty straightforward approach that, if adopted,
>>> eliminates an entire category of bugs.
>>> 
>>> The draft proposal is here:
>>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
>>> >> >
>>> 
>>> Thanks in advance for your thoughtful feedback,
>> 
>> +1 on the idea of this.  
> 
> ditto.  IMO it also makes the protocol extension much more expressive
> and easy to read.
> 
> -- 
> -Dave
> 
> ___
> 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] Followup after in-the-field feedback for SE-0170

[Philippe Hausler via swift-evolution]

> On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 14 2017, Philippe Hausler  > wrote:
> 
>> After implementing the proposal
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> >  
>> >
>> we have gotten some initial feedback.
>> 
>> It seems that there is definitely a fair amount of confusion and heartache 
>> for dealing with Float
>> and Double values being bridged.
>> 
>> Specifically the cases like:
>> 
>> NSNumber(value 0.1) as? Float
>> 
>> which with the current implementation will return nil since the Double value 
>> 0.1 cannot be
>> represented exactly as a Float.
>> 
>> It seems like the overwhelming majority of users know full well that
>> Float will result in a loss of precision (hence why they chose that
>> type over Double). This means that the floating point bridges for
>> Double, Float, and CGFloat should not be the pedantic “exactly” cases
>> but instead infer the conversion intent of a lax/approximated version.
> 
> +1
> 
>> So in short: for the betterment of the API ergonomics, the floating
>> point types as destinations will be pulled back to their initial Swift
>> 3 behavior.
>> 
>> Additionally to aide appropriate migration to the appropriate
>> truncating/exactly initializers the un-labeled, deprecated in Swift 4,
>> plain init methods to the numeric types with an NSNumber will now be
>> annotated with the suggested replacements.
> 
> Sorry, I don't quite understand what that last paragraph implies.  Could
> you describe what will be deprecated and what will be suggested instead?

https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4
 


So this is just an annotation of renaming to the init(truncating:)


> 
> -- 
> -Dave
> 
> ___
> 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] Followup after in-the-field feedback for SE-0170

[Philippe Hausler via swift-evolution]

is and as are implemented in the compiler to call the same method

Sent from my iPhone

> On Jun 14, 2017, at 1:38 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> In SE-0170, it states: "It is worth noting that `is` should follow the same 
> logic as `as?`." For clarity, does rolling back to the initial Swift 3 
> behavior mean that `NSNumber(value: 0.1) is Float == true`?
> 
>> On Wed, Jun 14, 2017 at 3:13 PM, Philippe Hausler via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> After implementing the proposal 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  we have gotten some initial feedback.
>> 
>> It seems that there is definitely a fair amount of confusion and heartache 
>> for dealing with Float and Double values being bridged. 
>> 
>> Specifically the cases like:
>> 
>> NSNumber(value 0.1) as? Float
>> 
>> which with the current implementation will return nil since the Double value 
>> 0.1 cannot be represented exactly as a Float.
>> 
>> It seems like the overwhelming majority of users know full well that Float 
>> will result in a loss of precision (hence why they chose that type over 
>> Double). This means that the floating point bridges for Double, Float, and 
>> CGFloat should not be the pedantic “exactly” cases but instead infer the 
>> conversion intent of a lax/approximated version.
>> 
>> So in short: for the betterment of the API ergonomics, the floating point 
>> types as destinations will be pulled back to their initial Swift 3 behavior.
>> 
>> Additionally to aide appropriate migration to the appropriate 
>> truncating/exactly initializers the un-labeled, deprecated in Swift 4, plain 
>> init methods to the numeric types with an NSNumber will now be annotated 
>> with the suggested replacements.
>> 
>> Thanks for your time and feedback,
>> Philippe Hausler
>> 
>> ___
>> 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

[swift-evolution] Followup after in-the-field feedback for SE-0170

[Philippe Hausler via swift-evolution]

After implementing the proposal 
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
 

 we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for 
dealing with Float and Double values being bridged. 

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 
0.1 cannot be represented exactly as a Float.

It seems like the overwhelming majority of users know full well that Float will 
result in a loss of precision (hence why they chose that type over Double). 
This means that the floating point bridges for Double, Float, and CGFloat 
should not be the pedantic “exactly” cases but instead infer the conversion 
intent of a lax/approximated version.

So in short: for the betterment of the API ergonomics, the floating point types 
as destinations will be pulled back to their initial Swift 3 behavior.

Additionally to aide appropriate migration to the appropriate 
truncating/exactly initializers the un-labeled, deprecated in Swift 4, plain 
init methods to the numeric types with an NSNumber will now be annotated with 
the suggested replacements.

Thanks for your time and feedback,
Philippe Hausler___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: String Index Overhaul

[Philippe Hausler via swift-evolution]

I would presume that the index type will still be shared between String and 
SubString, will this mean that we will now be able to express index 
manipulation in StringProtocol?

I find StringProtocol a bit hard to deal with when attempting to make range 
conversions; it would be really nice if we could make this possible (or perhaps 
more intuitive... since, for the life of me I can’t figure out a way to 
generically convert indexes for StringProtocol adoption)

So lets say you have a function as such: 

func foo(_ str: S, range: Range) {
range.lowerBound.samePosition(in: str.utf16)
}

results in the error error: value of type 'S.Index' has no member ‘samePosition’

This of course is an intended target of something that deals with strings and 
wants to deal with both strings and substrings uniformly since it is reasonable 
to pass either.

In short: are StringProtocol accessors a consideration for conversion in this 
change?

> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Pretty version: 
> https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/-string-index-overhaul.md
> 
> 
> 
> # String Index Overhaul
> 
> * Proposal: [SE-](-string-index-overhaul.md)
> * Authors: [Dave Abrahams](https://github.com/dabrahams)
> * Review Manager: TBD
> * Status: **Awaiting review**
> * Pull Request Implementing This Proposal: 
> https://github.com/apple/swift/pull/9806 
> 
> *During the review process, add the following fields as needed:*
> 
> ## Introduction
> 
> Today `String` shares an `Index` type with its `CharacterView` but not
> with its `UTF8View`, `UTF16View`, or `UnicodeScalarView`.  This
> proposal redefines `String.UTF8View.Index`, `String.UTF16View.Index`,
> and `String.CharacterView.Index` as typealiases for `String.Index`,
> and exposes a public `encodedOffset` property and initializer that can
> be used to serialize and deserialize positions in a `String` or
> `Substring`.
> 
> Swift-evolution thread: [Discussion thread topic for that 
> proposal](https://lists.swift.org/pipermail/swift-evolution/)
> 
> ## Motivation
> 
> The different index types are supported by a set of `Index`
> initializers, which are failable whenever the source index might not
> correspond to a position in the target view:
> 
> ```swift
> if let j = String.UnicodeScalarView.Index(
>  someUTF16Position, within: s.unicodeScalars) {
>  ... 
> }
> ```
> 
> The current API is as follows:
> 
> ```swift
> public extension String.Index {
>  init?(_: String.UnicodeScalarIndex, within: String)
>  init?(_: String.UTF16Index, within: String)
>  init?(_: String.UTF8Index, within: String)
> }
> 
> public extension String.UTF16View.Index {
>  init?(_: String.UTF8Index, within: String.UTF16View)
>  init(_: String.UnicodeScalarIndex, within: String.UTF16View)
>  init(_: String.Index, within: String.UTF16View)
> }
> 
> public extension String.UTF8View.Index {
>  init?(_: String.UTF16Index, within: String.UTF8View)
>  init(_: String.UnicodeScalarIndex, within: String.UTF8View)
>  init(_: String.Index, within: String.UTF8View)
> }
> 
> public extension String.UnicodeScalarView.Index {
>  init?(_: String.UTF16Index, within: String.UnicodeScalarView)
>  init?(_: String.UTF8Index, within: String.UnicodeScalarView)
>  init(_: String.Index, within: String.UnicodeScalarView)
> }
> ```
> 
> These initializers are supplemented by a corresponding set of
> convenience conversion methods:
> 
> ```swift
> if let j = someUTF16Position.samePosition(in: s.unicodeScalars) {
>  ... 
> }
> ```
> 
> with the following API:
> 
> ```swift
> public extension String.Index {
>  func samePosition(in: String.UTF8View) -> String.UTF8View.Index
>  func samePosition(in: String.UTF16View) -> String.UTF16View.Index
>  func samePosition(
>in: String.UnicodeScalarView) -> String.UnicodeScalarView.Index
> }
> 
> public extension String.UTF16View.Index {
>  func samePosition(in: String) -> String.Index?
>  func samePosition(in: String.UTF8View) -> String.UTF8View.Index?
>  func samePosition(
>in: String.UnicodeScalarView) -> String.UnicodeScalarView.Index?
> }
> 
> public extension String.UTF8View.Index {
>  func samePosition(in: String) -> String.Index?
>  func samePosition(in: String.UTF16View) -> String.UTF16View.Index?
>  func samePosition(
>in: String.UnicodeScalarView) -> String.UnicodeScalarView.Index?
> }
> 
> public extension String.UnicodeScalarView.Index {
>  func samePosition(in: String) -> String.Index?
>  func samePosition(in: String.UTF8View) -> String.UTF8View.Index
>  func samePosition(in: String.UTF16View) -> String.UTF16View.Index
> }
> ```
> 
> The result is a great deal of API surface area for apparently little
> gain in ordinary code, that normally only interchanges indices among
> views when the positions match up exactly (i.e. when the conversion is
> going to succeed).  Also, the resulting code is needlessly awkward.
> 
> Finally, the 

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Philippe Hausler via swift-evolution]

> On May 22, 2017, at 6:07 AM, Ben Rimmington  wrote:
> 
> 
>> On 20 May 2017, at 19:58, Philippe Hausler wrote:
>> 
>>> On May 20, 2017, at 12:25 AM, David Waite wrote:
>>> 
>>> I believe behavior depends on whether the NSNumber is the objc type or 
>>> swift subtype, and whether you call the NSNumber.intValue or use 
>>> Int.init?(exactly: NSNumber).
>> 
>> That part of the behavior is no longer the case. The bridge only transacts 
>> upon one number type (to leverage tagged pointers) and the subclass was 
>> removed (since it caused some gnarly inconsistencies)
> 
> The subclass `_SwiftTypePreservingNSNumber` still exists:
> 
> 

Hmm it shouldn’t, that looks like an oversight on my part if it is still alive.

> 
> Maybe the file isn't compiled anymore due to your pull requests:
> 
> 
> 

Correct. it should no longer be used (hopefully it isn’t bloating binaries with 
un-used code). I will look into this here shortly.

> 
> You mentioned tagged pointers. My understanding is that:
> 
> * `OBJC_TAG_NSNumber` doesn't attempt to store a `float` or `double` in the 
> 60-bit payload;

Integral double or float values are stored (when they can be). So 42.0 will be 
stored, but 53.5 won’t be. All other storage types (modulo NSDecimals) will 
store as a tagged pointer if they can; NSNumber(value: Int32.max) on a 64 bit 
system will be tagged but NSNumber(value: UInt64.max) of course won’t be.

The most common floating point NSNumbers are 0.0, 1.0, -1.0, 10.0, 22.0, 0.5. 
But it is worth noting that since we can construct NSNumbers as cached values 
or even as addresses of static structures (see 
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/NumberDate.subproj/CFNumber.c#L377
 
)



> * `OBJC_TAG_NSDate` is used only if bits 0...3 of the `NSTimeInterval` (aka 
> `double`) are zero.

NSDates are stored as 56 bits in the tagged pointer. 

> 
> 
> 
> How often is an NSDate (with "sub-millisecond precision") created as a tagged 
> pointer?

Not very often at all really. The most common dates are usually integral values.

> 
> — Ben
> 

To further give a bit of insight on tagged NSNumbers; using those instead of 
allocating a new instance each time accounts for about 1% on average for 
property lists. So this wasn’t really just a consistency change alone, it was 
execution time as well as memory fragmentation improvement.

It is also worth noting that as the overall system usage changes over time we 
might change our layout of tagged pointers (for both NSDate and NSNumber). So 
don’t rely on them being a certain way ;)





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

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Philippe Hausler via swift-evolution]

> On May 20, 2017, at 12:25 AM, David Waite via swift-evolution 
>  wrote:
> 
> I believe behavior depends on whether the NSNumber is the objc type or swift 
> subtype, and whether you call the NSNumber.intValue or use Int.init?(exactly: 
> NSNumber).
> 

That part of the behavior is no longer the case. The bridge only transacts upon 
one number type (to leverage tagged pointers) and the subclass was removed 
(since it caused some gnarly inconsistencies) 

> My point is that there is no intuitive or safe generalized behavior for 
> treating arbitrary NSNumbers as an Int? . If an application or library wants 
> to accept a NSNumber and treat it as an Int?, it should be responsible for 
> declaring that method and implementing that logic.

But you are absolutely correct; NSNumber should be though of as a 
AnyNumericValue box where the type of the number is erased but the value is not.

Interesting cases include:

NSNumber(value: 3.0) as? Int == 3

Or 

NSNumber(value: UInt64(121)) as? Int8 == Int8(121)

The SE-0170 proposal also added initializers for truncating and exactly that 
work much more on par with the rest of the numeric system in swift. (However it 
did un-cover a few nasty floating point bugs in the unit tests but the intent 
of the behavior is matched)

The other consideration that might be interesting to further your point that 
nullable NSNumber * as a representation of Int? Is a bit off is that often 
“optional” integers in objc are actually PoD types with sentry values; e.g. 
NSNotFound etc. So in reality we would need some sort of annotation on how the 
bridge of a numeric type should be represented to indicate a nullable value 
that is exposed as an integer or float etc.

> 
> -DW
> 
>> On May 19, 2017, at 11:04 PM, Jonathan Hull > > wrote:
>> 
>> What happens now if you call integerValue if a NSNumber has these values?
>> 
>> 
>>> On May 19, 2017, at 9:00 PM, David Waite >> > wrote:
>>> 
>>> When I call such a mapped Swift API that expects an Int? parameter from 
>>> Objc with a NSNumber initialized with 3.5, what should happen? 
>>> 
>>> [NSNumber uint64value: UINT64_MAX] ?
>>> 
>>> What about the float 1e100? 
>>> 
>>> What about boolean 'true’? 
>>> 
>>> NaN?
>>> 
>>> -DW
>>> 
 On May 19, 2017, at 8:54 PM, Jonathan Hull via swift-evolution 
 > wrote:
 
 I have to side with Kenny on this one.  I would find losing nil vs 0 more 
 surprising than NSInteger vs NSNumber.  In fact, I was surprised that this 
 doesn’t already cross to a NSNumber. That would be the behavior I expect.
 
 Thanks,
 Jon
 
 
> On May 16, 2017, at 11:51 AM, Kenny Leung via swift-evolution 
> > wrote:
> 
> But my argument *is* that optionality is an obvious way to make that 
> decision.
> 
> If I was writing in pure Objective-C (outside the context of Swift), 
> sometimes I would have methods that take or return int, and sometimes I 
> would have methods that take or return NSNumber. There is never really a 
> surprise as to why. So why would there be a surprise when bridging from 
> Swift?
> 
> -Kenny
> 
> 
>> On May 15, 2017, at 7:24 AM, T.J. Usiyan > > wrote:
>> 
>> The argument is not about whether or not it should come through as an 
>> object. The argument is about the fact that *sometimes* it would come 
>> through as an object and other times it would not. Optionality isn't an 
>> obvious way to make that decision.
>> 
>> TJ
>> 
>> On Mon, May 15, 2017 at 3:03 PM, Charlie Monroe 
>> > wrote:
>> This is not much of an argument given that NSString is an object in ObjC 
>> (heap-allocated), String in Swift is an struct and also given that most 
>> NSNumber's nowadays are not really allocated, but just tagged pointers.
>> 
>> Given that NSNumber is immutable, you get the value semantics anyway...
>> 
>>> On May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution 
>>> > wrote:
>>> 
>>> My understanding of the reasoning is that `NSNumber` is an object in 
>>> Objective-C and not a struct. There is already one level of decision 
>>> when translating to objc in that regard. Switching between reference 
>>> semantics/class and value semantics because of optionality is 
>>> surprising.
>>> 
>>> On Mon, May 15, 2017 at 5:52 AM, Kenny Leung via swift-evolution 
>>> > wrote:
>>> > On May 12, 2017, at 9:56 AM, 

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Philippe Hausler via swift-evolution]

With the introduction of SE-0170 the behavior is a bit more predicable: The 
rule is that if the value would not loose mantissa representation or 
significant bits of the representation it will bridge to the target type in all 
scenarios, no matter if it is created in objc or in swift.

> On May 19, 2017, at 9:00 PM, David Waite via swift-evolution 
>  wrote:
> 
> When I call such a mapped Swift API that expects an Int? parameter from Objc 
> with a NSNumber initialized with 3.5, what should happen? 

NSNumber(value: 3.5) as? Int == nil

But

NSNumber(value: 3.5).intValue == 3

> 
> [NSNumber uint64value: UINT64_MAX] ?

NSNumber(value: UInt64.max) as? Int == nil

> 
> What about the float 1e100?

NSNumber(value: 1.0e100) as? Int == nil

>  
> 
> What about boolean 'true’? 

NSNumber(value: true) as? Int == 1

> 
> NaN?

NSNumber(value: Double.nan) as? Int == nil

> 
> -DW
> 
>> On May 19, 2017, at 8:54 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> I have to side with Kenny on this one.  I would find losing nil vs 0 more 
>> surprising than NSInteger vs NSNumber.  In fact, I was surprised that this 
>> doesn’t already cross to a NSNumber. That would be the behavior I expect.
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On May 16, 2017, at 11:51 AM, Kenny Leung via swift-evolution 
>>> > wrote:
>>> 
>>> But my argument *is* that optionality is an obvious way to make that 
>>> decision.
>>> 
>>> If I was writing in pure Objective-C (outside the context of Swift), 
>>> sometimes I would have methods that take or return int, and sometimes I 
>>> would have methods that take or return NSNumber. There is never really a 
>>> surprise as to why. So why would there be a surprise when bridging from 
>>> Swift?
>>> 
>>> -Kenny
>>> 
>>> 
 On May 15, 2017, at 7:24 AM, T.J. Usiyan > wrote:
 
 The argument is not about whether or not it should come through as an 
 object. The argument is about the fact that *sometimes* it would come 
 through as an object and other times it would not. Optionality isn't an 
 obvious way to make that decision.
 
 TJ
 
 On Mon, May 15, 2017 at 3:03 PM, Charlie Monroe > wrote:
 This is not much of an argument given that NSString is an object in ObjC 
 (heap-allocated), String in Swift is an struct and also given that most 
 NSNumber's nowadays are not really allocated, but just tagged pointers.
 
 Given that NSNumber is immutable, you get the value semantics anyway...
 
> On May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution 
> > wrote:
> 
> My understanding of the reasoning is that `NSNumber` is an object in 
> Objective-C and not a struct. There is already one level of decision when 
> translating to objc in that regard. Switching between reference 
> semantics/class and value semantics because of optionality is surprising.
> 
> On Mon, May 15, 2017 at 5:52 AM, Kenny Leung via swift-evolution 
> > wrote:
> > On May 12, 2017, at 9:56 AM, John McCall via swift-evolution 
> > > wrote:
> 
> > Exporting Int? as an optional NSNumber does not feel obvious and 
> > idiomatic when we would export Int as NSInteger.  It feels like 
> > reaching for an arbitrary solution.
> 
> I don’t understand this reasoning. I’ve had cause to distinguish 0 from 
> null in both Objective-C and Java, and I would do exactly the same thing.
> 
> -Kenny
> 
> ___
> 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 
> 
 
 
>>> 
>>> ___
>>> 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] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

the purposes of bridging 
>>>>> NSNumber, if the answer is that the implementation parses JSON numbers as 
>>>>> double-precision values, Double(exactly:) would be the right choice; 
>>>>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the 
>>>>> right choice, etc.
>>>>> 
>>>> 
>>>> Float80 is not compatible with NSNumber; and is well out of scope for this 
>>>> proposal.
>>> 
>>> OK, so Double is the largest floating point type compatible with NSNumber? 
>>> It stands to reason that any Swift JSON implementation that uses NSNumber 
>>> for parsed floating point values would at most have that much range and 
>>> precision, right?
>> 
>> For JSONSerialization (which I am most familiar with and ships with 
>> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
>> approximation of the behavior: if it can store the value in an integer type 
>> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it 
>> has a decimal point it will attempt to parse as a double but if that is not 
>> enough storage it will store the best possible value into NSDecimalNumber. 
>> 
>> So NSNumber itself (excluding subclasses) can only store up to a 64 bit 
>> value. 
>> 
>>> 
>>> If so, then every floating point value parsed by any such Swift JSON 
>>> implementation would be exactly representable as a Double: regardless of 
>>> whether that specific implementation uses Float or Double under the hood, 
>>> every Float can be represented exactly as a Double. If a user is trying to 
>>> bridge such a NSNumber instance specifically to *Float* instead of Double, 
>>> and they are asking for an exact value, there's no a priori reason to think 
>>> that this user would be more likely to care only about the range and not 
>>> the precision, or vice versa. Which is to say, I don't think you'll get too 
>>> many bug reports :)
>> 
>> In my mind there are two considerations here; balance against the surprise 
>> from new developers learning their first programming language versus 
>> consistency. In the end even if I believe the behavior is sub-par I would 
>> rather it be consistent. Primarily consistency is easier to teach even if it 
>> is derived from a standard developed with legacy behavior of C at its heart.
>> 
>> Perhaps in the future we might want to eventually allow conversions to and 
>> from NSNumber via the Integer and FloatingPoint protocols; however I would 
>> guess that there needs to be a lot more thought and perhaps some 
>> modifications there to pull that off. Not to sound like a broken record, but 
>> again that it is out of scope for right now.
>> 
>>> 
>>>>> 
>>>>>> After thinking about it more; it seems reasonable to restrict it to the 
>>>>>> behavior of Float(exactly: Double(…)). I am certain this will probably 
>>>>>> in the end cause more bugs for me to have to address and mark as 
>>>>>> “behaves correctly” and confuse a few new developers - but in the end 
>>>>>> they chose Swift and the consistent story would be the current behavior 
>>>>>> of Float(exactly: Double).
>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler 
>>>>>>>>>> <phaus...@apple.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>>>>>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It seems Float.init(exactly: NSNumber) has not been updated to 
>>>>>>>>>>>>> behave similarly?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I would have to say, I would naively expect "exactly" to behave 
>>>>>>>>>>>>> exactly as it says, exactly. I don't think it should be a synonym 
>>>>>>>>>>>>> for Float(Double(exactly:)).
>>>>>>>>>>>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via 
>>>>>>>>>>>>> swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>>>>>>> I posted my branch and fixed up the Double case to account for 
>>>>>>>>>>>>> your concerns (with a few inspired unit tests to validate)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There is a builtin assumption here though: it does presume that 
>>>>>>>>>>>>> the swift’s representation of Double and Float are IEEE 
>>>>>>>>>>>>> compliant. However that is a fairly reasonable assumption in the 
>>>>>>>>>>>>> tests.
>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Even with the updated code at 
>>>>>>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>>>>>>> 
>>>>>>>> print(Double(exactly: NSNumber(value: Int64(901))) 
>>>>>>>> as Any)
>>>>>>>> // Optional(9e+18)
>>>>>>>> 
>>>>>>>> still succeeds, however the reason seems to be an error in the 
>>>>>>>> `init(exactly value: someIntegerType)` inititializers of Float/Double, 
>>>>>>>> I have submitted a bug report: https://bugs.swift.org/browse/SR-4634.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>>> (+Steve Canon) What is the behavior of Float.init(exactly: 
>>>>>>>>>>>> Double)? NSNumber's behavior would ideally be consistent with that.
>>>>>>>>>>> 
>>>>>>>>>>> The implementation is essentially just:
>>>>>>>>>>> 
>>>>>>>>>>> self.init(other)
>>>>>>>>>>> guard Double(self) == other else {
>>>>>>>>>>> return nil
>>>>>>>>>>> }
>>>>>>>>>>> 
>>>>>>>>>>> i.e. if the result is not equal to the source when round-tripped 
>>>>>>>>>>> back to double (which is always exact), the result is nil.
>>>>>>>>>>> 
>>>>>>>>>>> – Steve
>>>>>>>>>> 
>>>>>>>>>> Pretty much the same trick inside of CFNumber/NSNumber
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

ble under the hood, 
> every Float can be represented exactly as a Double. If a user is trying to 
> bridge such a NSNumber instance specifically to *Float* instead of Double, 
> and they are asking for an exact value, there's no a priori reason to think 
> that this user would be more likely to care only about the range and not the 
> precision, or vice versa. Which is to say, I don't think you'll get too many 
> bug reports :)

In my mind there are two considerations here; balance against the surprise from 
new developers learning their first programming language versus consistency. In 
the end even if I believe the behavior is sub-par I would rather it be 
consistent. Primarily consistency is easier to teach even if it is derived from 
a standard developed with legacy behavior of C at its heart.

Perhaps in the future we might want to eventually allow conversions to and from 
NSNumber via the Integer and FloatingPoint protocols; however I would guess 
that there needs to be a lot more thought and perhaps some modifications there 
to pull that off. Not to sound like a broken record, but again that it is out 
of scope for right now.

> 
>> 
>> After thinking about it more; it seems reasonable to restrict it to the 
>> behavior of Float(exactly: Double(…)). I am certain this will probably in 
>> the end cause more bugs for me to have to address and mark as “behaves 
>> correctly” and confuse a few new developers - but in the end they chose 
>> Swift and the consistent story would be the current behavior of 
>> Float(exactly: Double).
>> 
>>> 
>>>> 
>>>> 
>>>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phaus...@apple.com 
>>>> <mailto:phaus...@apple.com>> wrote:
>>>> 
>>>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com 
>>>>> <mailto:sca...@apple.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com 
>>>>>> <mailto:jgr...@apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> 
>>>>>>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>>>>>>> similarly?
>>>>>>> 
>>>>>>> I would have to say, I would naively expect "exactly" to behave exactly 
>>>>>>> as it says, exactly. I don't think it should be a synonym for 
>>>>>>> Float(Double(exactly:)).
>>>>>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> I posted my branch and fixed up the Double case to account for your 
>>>>>>> concerns (with a few inspired unit tests to validate)
>>>>>>> 
>>>>>>> https://github.com/phausler/swift/tree/safe_nsnumber 
>>>>>>> <https://github.com/phausler/swift/tree/safe_nsnumber>
>>>>>>> 
>>>>>>> There is a builtin assumption here though: it does presume that the 
>>>>>>> swift’s representation of Double and Float are IEEE compliant. However 
>>>>>>> that is a fairly reasonable assumption in the tests.
>>>>>> 
>>> 
>>> 
>>> Even with the updated code at 
>>> https://github.com/phausler/swift/tree/safe_nsnumber 
>>> <https://github.com/phausler/swift/tree/safe_nsnumber>
>>> 
>>> print(Double(exactly: NSNumber(value: Int64(901))) as 
>>> Any)
>>> // Optional(9e+18)
>>> 
>>> still succeeds, however the reason seems to be an error in the 
>>> `init(exactly value: someIntegerType)` inititializers of Float/Double, I 
>>> have submitted a bug report: https://bugs.swift.org/browse/SR-4634 
>>> <https://bugs.swift.org/browse/SR-4634>.
>>> 
>>> 
>>>>>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
>>>>>> NSNumber's behavior would ideally be consistent with that.
>>>>> 
>>>>> The implementation is essentially just:
>>>>> 
>>>>>   self.init(other)
>>>>>   guard Double(self) == other else {
>>>>>   return nil
>>>>>   }
>>>>> 
>>>>> i.e. if the result is not equal to the source when round-tripped back to 
>>>>> double (which is always exact), the result is nil.
>>>>> 
>>>>> – Steve
>>>> 
>>>> Pretty much the same trick inside of CFNumber/NSNumber

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 16:17, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler <phaus...@apple.com 
> <mailto:phaus...@apple.com>> wrote:
> 
>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr...@gmail.com 
>> <mailto:martinr...@gmail.com>> wrote:
>>> On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
>>> expect NSNumber to behave similarly (a notion with which Martin disagrees, 
>>> I guess). I don't see a test that shows whether NSNumber behaves or does 
>>> not behave in that way.
>> 
>> At present they behave differently: 
>> 
>> print(Float(exactly: Double.pi) as Any)
>> // nil
>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>> // Optional(3.14159274)
>> 
>> I realize that identical behavior would be logical and least surprising. My 
>> only concern was about cases like
>> 
>> let num = ... // some NSNumber from a JSON deserialization
>> let fval = Float(exactly: num)
>> 
>> where one cannot know how the number is represented internally and what 
>> precision it needs. But then one could use the truncating conversion or 
>> `.floatValue` instead.
>> 
>> JSON numbers are double-precision floating point, unless I'm 
>> misunderstanding something. If someone writes `Float(exactly: 
>> valueParsedFromJSON)`, surely, that can only mean that they *really, really* 
>> prefer nil over an imprecise value. I can see no other reason to insist on 
>> using both Float and .init(exactly:).
> 
> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
> infinite bit floating point :(
> 
> 
> Oops, you're right. I see they've wanted to future-proof this. That said, RFC 
> 7159 *does* say:
> 
> This specification allows implementations to set limits on the range
> and precision of numbers accepted.  Since software that implements
> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
> generally available and widely used, good interoperability can be
> achieved by implementations that expect no more precision or range
> than these provide, in the sense that implementations will
> approximate JSON numbers within the expected precision.
> 
> So JSON doesn't set limits on how numbers are represented, but JSON 
> implementations are permitted to (and I'd imagine that all in fact do). A 
> user of a JSON deserialization library can rightly expect to know the numeric 
> limits of that implementation; for the purposes of bridging NSNumber, if the 
> answer is that the implementation parses JSON numbers as double-precision 
> values, Double(exactly:) would be the right choice; otherwise, if it's 80-bit 
> values, then Float80(exactly:) would be the right choice, etc.
> 

Float80 is not compatible with NSNumber; and is well out of scope for this 
proposal.

> 
> After thinking about it more; it seems reasonable to restrict it to the 
> behavior of Float(exactly: Double(…)). I am certain this will probably in the 
> end cause more bugs for me to have to address and mark as “behaves correctly” 
> and confuse a few new developers - but in the end they chose Swift and the 
> consistent story would be the current behavior of Float(exactly: Double).
> 
>> 
>>> 
>>> 
>>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phaus...@apple.com 
>>> <mailto:phaus...@apple.com>> wrote:
>>> 
>>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com 
>>>> <mailto:sca...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com 
>>>>> <mailto:jgr...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> 
>>>>>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>>>>>> similarly?
>>>>>> 
>>>>>> I would have to say, I would naively expect "exactly" to behave exactly 
>>>>>> as it says, exactly. I don't think it should be a synonym for 
>>>>>&g

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr...@gmail.com 
> <mailto:martinr...@gmail.com>> wrote:
>> On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
>> expect NSNumber to behave similarly (a notion with which Martin disagrees, I 
>> guess). I don't see a test that shows whether NSNumber behaves or does not 
>> behave in that way.
> 
> At present they behave differently: 
> 
> print(Float(exactly: Double.pi) as Any)
> // nil
> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
> // Optional(3.14159274)
> 
> I realize that identical behavior would be logical and least surprising. My 
> only concern was about cases like
> 
> let num = ... // some NSNumber from a JSON deserialization
> let fval = Float(exactly: num)
> 
> where one cannot know how the number is represented internally and what 
> precision it needs. But then one could use the truncating conversion or 
> `.floatValue` instead.
> 
> JSON numbers are double-precision floating point, unless I'm misunderstanding 
> something. If someone writes `Float(exactly: valueParsedFromJSON)`, surely, 
> that can only mean that they *really, really* prefer nil over an imprecise 
> value. I can see no other reason to insist on using both Float and 
> .init(exactly:).

JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
infinite bit floating point :(

After thinking about it more; it seems reasonable to restrict it to the 
behavior of Float(exactly: Double(…)). I am certain this will probably in the 
end cause more bugs for me to have to address and mark as “behaves correctly” 
and confuse a few new developers - but in the end they chose Swift and the 
consistent story would be the current behavior of Float(exactly: Double).

> 
>> 
>> 
>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phaus...@apple.com 
>> <mailto:phaus...@apple.com>> wrote:
>> 
>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com 
>>> <mailto:sca...@apple.com>> wrote:
>>> 
>>>> 
>>>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com 
>>>> <mailto:jgr...@apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>>>>> similarly?
>>>>> 
>>>>> I would have to say, I would naively expect "exactly" to behave exactly 
>>>>> as it says, exactly. I don't think it should be a synonym for 
>>>>> Float(Double(exactly:)).
>>>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> I posted my branch and fixed up the Double case to account for your 
>>>>> concerns (with a few inspired unit tests to validate)
>>>>> 
>>>>> https://github.com/phausler/swift/tree/safe_nsnumber 
>>>>> <https://github.com/phausler/swift/tree/safe_nsnumber>
>>>>> 
>>>>> There is a builtin assumption here though: it does presume that the 
>>>>> swift’s representation of Double and Float are IEEE compliant. However 
>>>>> that is a fairly reasonable assumption in the tests.
>>>> 
> 
> 
> Even with the updated code at 
> https://github.com/phausler/swift/tree/safe_nsnumber 
> <https://github.com/phausler/swift/tree/safe_nsnumber>
> 
> print(Double(exactly: NSNumber(value: Int64(901))) as Any)
> // Optional(9e+18)
> 
> still succeeds, however the reason seems to be an error in the `init(exactly 
> value: someIntegerType)` inititializers of Float/Double, I have submitted a 
> bug report: https://bugs.swift.org/browse/SR-4634 
> <https://bugs.swift.org/browse/SR-4634>.
> 
> 
>>>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
>>>> NSNumber's behavior would ideally be consistent with that.
>>> 
>>> The implementation is essentially just:
>>> 
>>> self.init(other)
>>> guard Double(self) == other else {
>>> return nil
>>> }
>>> 
>>> i.e. if the result is not equal to the source when round-tripped back to 
>>> double (which is always exact), the result is nil.
>>> 
>>> – Steve
>> 
>> Pretty much the same trick inside of CFNumber/NSNumber

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com> wrote:
> 
>> 
>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com> wrote:
>> 
>> 
>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>>> similarly?
>>> 
>>> I would have to say, I would naively expect "exactly" to behave exactly as 
>>> it says, exactly. I don't think it should be a synonym for 
>>> Float(Double(exactly:)).
>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> I posted my branch and fixed up the Double case to account for your 
>>> concerns (with a few inspired unit tests to validate)
>>> 
>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>> 
>>> There is a builtin assumption here though: it does presume that the swift’s 
>>> representation of Double and Float are IEEE compliant. However that is a 
>>> fairly reasonable assumption in the tests.
>> 
>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
>> NSNumber's behavior would ideally be consistent with that.
> 
> The implementation is essentially just:
> 
>   self.init(other)
>   guard Double(self) == other else {
>   return nil
>   }
> 
> i.e. if the result is not equal to the source when round-tripped back to 
> double (which is always exact), the result is nil.
> 
> – Steve

Pretty much the same trick inside of CFNumber/NSNumber___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

The unit tests seem to show that is not needed due to the internal 
implementation of NSNumber.

> On Apr 17, 2017, at 17:56, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> It seems Float.init(exactly: NSNumber) has not been updated to behave 
> similarly?
> 
> I would have to say, I would naively expect "exactly" to behave exactly as it 
> says, exactly. I don't think it should be a synonym for 
> Float(Double(exactly:)).

There are a few outliers with that: +/-infinity, nan, and values exceeding 
+/-Double(Float.greatestFiniteMagnitude) iiuc will trap in that expression.

If you take a peek at my unit tests; 
https://github.com/phausler/swift/blob/safe_nsnumber/test/stdlib/NSNumberBridging.swift#L800
 
<https://github.com/phausler/swift/blob/safe_nsnumber/test/stdlib/NSNumberBridging.swift#L800>

That should verify that float values are properly handled in terms of exactly 
per the casting rules - This is part of the assumption that both float and 
double values in swift are IEEE compliant since NSNumber itself stores 
accordingly. I have tests in place to verify from -1 mantissa bits to +1 
mantissa bits conversions from UInt64 and Int64. 

That all being said: I would be happy to add any additional tests to verify the 
expected behavior.


> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I posted my branch and fixed up the Double case to account for your concerns 
> (with a few inspired unit tests to validate)
> 
> https://github.com/phausler/swift/tree/safe_nsnumber 
> <https://github.com/phausler/swift/tree/safe_nsnumber>
> 
> There is a builtin assumption here though: it does presume that the swift’s 
> representation of Double and Float are IEEE compliant. However that is a 
> fairly reasonable assumption in the tests.
> 
>> On Apr 15, 2017, at 13:12, Philippe Hausler <phaus...@apple.com 
>> <mailto:phaus...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Apr 14, 2017, at 22:51, Martin R <martinr...@gmail.com 
>>> <mailto:martinr...@gmail.com>> wrote:
>>> 
>>> Thank you for the response, but I have more questions. Will
>>> 
>>> Float(exactly: NSNumber(value: Double.pi))
>> 
>> This will succeed in that the value is representable without loosing mantissa
>> 
>>> 
>>> fail because Float cannot represent the number Double.pi exactly? Or
>>> 
>>> Double(exactly: NSDecimalNumber(string: "1.9”))
>> 
>> Again it would be representable without losing mantissa but… 
>> 
>>> 
>>> because Double cannot represent the decimal fraction 1.9 exactly?
>> 
>> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope 
>> of this proposal (it is it’s own type and bridges to Decimal)
>> 
>>> 
>>> I find it difficult to evaluate the proposal without a description of the 
>>> intended behavior of the "exact" conversions which covers all possible 
>>> combinations (integers, floating point values, booleans). At present, the 
>>> behavior is described only for stored integer types.
>> 
>> I can post the patch but the real machinery is in NSNumber itself. The 
>> primary test is that if the value can round trip as the expected type and 
>> evaluate to equal to a NSNumber it will.
>> 
>> The conversion roughy is a cast to and from the stored type;
>> 
>> extension Double {
>>  init?(exactly number: NSNumber) {
>>  let value = number.doubleValue
>>  guard NSNumber(value: value) == number else { return nil }
>>  self = value
>>  }
>> }
>> 
>> The effective result of this is a verification of the stored type being 
>> equal to the fetched value. But specifically this only traverses via tagged 
>> pointers (if the are present). It is worth noting that this is not the exact 
>> implementation but an approximation with public apis.
>> 
>> Overall this is by far a better behavior than just permissively allowing all 
>> conversions (which is the current alternative of doing nothing…). As one of 
>> the responsible maintainers for NSNumber I would claim that a generally 
>> permissive cast as it is today is incorrect usage of NSNumber.
>> 
>>> 
>>> Regards, Martin
>>> 
>>>> On 14. Apr 2017, at 23:23, Philippe Hausler <phaus...@apple.com 
>>>> <mailto:phaus...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

I posted my branch and fixed up the Double case to account for your concerns 
(with a few inspired unit tests to validate)

https://github.com/phausler/swift/tree/safe_nsnumber 


There is a builtin assumption here though: it does presume that the swift’s 
representation of Double and Float are IEEE compliant. However that is a fairly 
reasonable assumption in the tests.

> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
> 
> 
> 
>> On Apr 14, 2017, at 22:51, Martin R > > wrote:
>> 
>> Thank you for the response, but I have more questions. Will
>> 
>> Float(exactly: NSNumber(value: Double.pi))
> 
> This will succeed in that the value is representable without loosing mantissa
> 
>> 
>> fail because Float cannot represent the number Double.pi exactly? Or
>> 
>> Double(exactly: NSDecimalNumber(string: "1.9”))
> 
> Again it would be representable without losing mantissa but… 
> 
>> 
>> because Double cannot represent the decimal fraction 1.9 exactly?
> 
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
> this proposal (it is it’s own type and bridges to Decimal)
> 
>> 
>> I find it difficult to evaluate the proposal without a description of the 
>> intended behavior of the "exact" conversions which covers all possible 
>> combinations (integers, floating point values, booleans). At present, the 
>> behavior is described only for stored integer types.
> 
> I can post the patch but the real machinery is in NSNumber itself. The 
> primary test is that if the value can round trip as the expected type and 
> evaluate to equal to a NSNumber it will.
> 
> The conversion roughy is a cast to and from the stored type;
> 
> extension Double {
>   init?(exactly number: NSNumber) {
>   let value = number.doubleValue
>   guard NSNumber(value: value) == number else { return nil }
>   self = value
>   }
> }
> 
> The effective result of this is a verification of the stored type being equal 
> to the fetched value. But specifically this only traverses via tagged 
> pointers (if the are present). It is worth noting that this is not the exact 
> implementation but an approximation with public apis.
> 
> Overall this is by far a better behavior than just permissively allowing all 
> conversions (which is the current alternative of doing nothing…). As one of 
> the responsible maintainers for NSNumber I would claim that a generally 
> permissive cast as it is today is incorrect usage of NSNumber.
> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 23:23, Philippe Hausler >> > wrote:
>>> 
 
 On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
 > wrote:
 
 Apologies if I am overlooking something, but it seems to me that the 
 proposal does not clearly define the behavior of the "exact" conversions 
 between integer and floating point values. Does
 
 Int(exactly: NSNumber(value: 12.34))
>>> 
>>> The exact value of a float or double constructed NSNumber will only happen 
>>> for integral values: e.g. 1.0, -32.0 etc
>>> 
 
 fail because Int cannot represent the number exactly? Or are floating 
 point values truncated silently and the conversion to an integer fails 
 only if it overflows? And the other way around: Does
 
 Double(exactly: NSNumber(value: Int64(901)))
 
 fail because Double cannot represent the number exactly?
>>> 
>>> I believe this will fail because the Int64 value will exceed the mantissa 
>>> representation of the Double from my current implementation. 
>>> 
 
 Regards, Martin
 
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
> > wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be 
> pointing to the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>> On Apr 14, 2017, at 11:30 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
>> and runs through the Friday after next, April 14th. The proposal is 
>> available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> Reviews are an important part of the Swift evolution 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 14, 2017, at 22:51, Martin R  wrote:
> 
> Thank you for the response, but I have more questions. Will
> 
> Float(exactly: NSNumber(value: Double.pi))

This will succeed in that the value is representable without loosing mantissa

> 
> fail because Float cannot represent the number Double.pi exactly? Or
> 
> Double(exactly: NSDecimalNumber(string: "1.9”))

Again it would be representable without losing mantissa but… 

> 
> because Double cannot represent the decimal fraction 1.9 exactly?

Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
this proposal (it is it’s own type and bridges to Decimal)

> 
> I find it difficult to evaluate the proposal without a description of the 
> intended behavior of the "exact" conversions which covers all possible 
> combinations (integers, floating point values, booleans). At present, the 
> behavior is described only for stored integer types.

I can post the patch but the real machinery is in NSNumber itself. The primary 
test is that if the value can round trip as the expected type and evaluate to 
equal to a NSNumber it will.

The conversion roughy is a cast to and from the stored type;

extension Double {
init?(exactly number: NSNumber) {
let value = number.doubleValue
guard NSNumber(value: value) == number else { return nil }
self = value
}
}

The effective result of this is a verification of the stored type being equal 
to the fetched value. But specifically this only traverses via tagged pointers 
(if the are present). It is worth noting that this is not the exact 
implementation but an approximation with public apis.

Overall this is by far a better behavior than just permissively allowing all 
conversions (which is the current alternative of doing nothing…). As one of the 
responsible maintainers for NSNumber I would claim that a generally permissive 
cast as it is today is incorrect usage of NSNumber.

> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 23:23, Philippe Hausler > > wrote:
>> 
>>> 
>>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>>> > wrote:
>>> 
>>> Apologies if I am overlooking something, but it seems to me that the 
>>> proposal does not clearly define the behavior of the "exact" conversions 
>>> between integer and floating point values. Does
>>> 
>>> Int(exactly: NSNumber(value: 12.34))
>> 
>> The exact value of a float or double constructed NSNumber will only happen 
>> for integral values: e.g. 1.0, -32.0 etc
>> 
>>> 
>>> fail because Int cannot represent the number exactly? Or are floating point 
>>> values truncated silently and the conversion to an integer fails only if it 
>>> overflows? And the other way around: Does
>>> 
>>> Double(exactly: NSNumber(value: Int64(901)))
>>> 
>>> fail because Double cannot represent the number exactly?
>> 
>> I believe this will fail because the Int64 value will exceed the mantissa 
>> representation of the Double from my current implementation. 
>> 
>>> 
>>> Regards, Martin
>>> 
 On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
 > wrote:
 
 Apologies, if you are reading this in HTML the links appear to be pointing 
 to the incorrect proposal. 
 
 Here is the corrected link:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
  
 
 
> On Apr 14, 2017, at 11:30 AM, Ben Cohen  > wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
> and runs through the Friday after next, April 14th. The proposal is 
> available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the 
> review manager. When replying, please try to keep the proposal link at 
> the top of the message:
> 
>   Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>   Reply text
> 
>   Other replies

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>  wrote:
> 
> Apologies if I am overlooking something, but it seems to me that the proposal 
> does not clearly define the behavior of the "exact" conversions between 
> integer and floating point values. Does
> 
> Int(exactly: NSNumber(value: 12.34))

The exact value of a float or double constructed NSNumber will only happen for 
integral values: e.g. 1.0, -32.0 etc

> 
> fail because Int cannot represent the number exactly? Or are floating point 
> values truncated silently and the conversion to an integer fails only if it 
> overflows? And the other way around: Does
> 
> Double(exactly: NSNumber(value: Int64(901)))
> 
> fail because Double cannot represent the number exactly?

I believe this will fail because the Int64 value will exceed the mantissa 
representation of the Double from my current implementation. 

> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Apologies, if you are reading this in HTML the links appear to be pointing 
>> to the incorrect proposal. 
>> 
>> Here is the corrected link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> 
>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
>>> runs through the Friday after next, April 14th. The proposal is available 
>>> here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>>  
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>>  
>>> 
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> • What is your evaluation of the proposal?
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> • Does this proposal fit well with the feel and direction of Swift?
>>> • 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?
>>> 
>>> More information about the Swift evolution process is available at 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thank you,
>>> 
>>> Ben Cohen
>>> Review Manager
>>> 
>>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Philippe Hausler via swift-evolution]

> On Mar 23, 2017, at 10:14 AM, Jordan Rose  wrote:
> 
>> 
>> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution 
 > wrote:
 
 Alternatives considered
 
 Do nothing and continue to accept this implicit conversion.
>>> 
>>> One alternative would be to import CFArray as a typealias for NSArray, etc, 
>>> erasing the distinction between the two types completely. I did suggest 
>>> this to Jordan at one point and he pointed out some problems, but I don’t 
>>> remember them now. Hopefully Jordan can chime in.
>> 
>> I'd prefer this solution as well, especially since toll-free bridged CF 
>> types are nearly indistinguishable from their NS counterparts at runtime, so 
>> trying to maintain the distinction for dynamic casts or reflection has 
>> historically been problematic. Part of the problem is that, as Charlie 
>> noted, CFArray/Dictionary/Set can take an arbitrary set of retain/release 
>> callbacks, in which case the resulting container isn't fully 
>> NSArray-compatible. I'm not sure that happens often enough with CF 
>> containers in the SDKs that accounting for that case is worth the burden of 
>> separating the types.
> 
> [adding Philippe, who has also thought about this problem]
> 
> The abstract problems I know of are:
> 
> (1) custom callbacks
> (2) it's legal to import CF without importing Foundation
> (3) CF types will not get generics
> 
> In practice, (1) is both exceedingly rare (only one public API that I know 
> of) and something that can be worked around by using the CF APIs on the 
> array—that is, we can keep CFArrayGetValueAtIndex around and just have it 
> take an NSArray. (2) is something we can deprecate and/or fix. (3) just means 
> we have to import the CFArray as NSArray rather than Array.
> 
> We would have to be very sure that all toll-free bridged CF types are marked 
> as such; adding toll-free bridging would not be a backwards-compatible change 
> since it would conflate two types into one. This leads us to a fourth 
> problem: this is a source-breaking change if anyone has overloads for both 
> CFArray and NSArray, or adds a protocol to CFArray that NSArray already has. 
> We probably already need to solve the latter in some way, and could try to 
> cross our fingers about the former.
> 
> Jordan


I think there are a bit more ramifications that are under the hood here; we 
should consider the full extent of what changing the behavior between CF types 
and NS types a bit more deeply than just a cursory proposal. Additionally as 
with any change to Foundation and CoreFoundation this should be passed around 
internally to the appropriate stakeholders that will be in charge of providing 
long term support for any sort of change this would apply to.

As an initial gut reaction; I would say that this is well past our stage for 
changes for Foundation and I would hate to see something be pushed out last 
minute that takes away development time from other important tasks on the table.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Factory Initializers

[Philippe Hausler via swift-evolution]

I am really glad to see this up again. It is definitely something that I am 
quite certain that all of the Foundation team and contriubters are quite 
enthusiastic about.

I know it would likely mean some extra work for the compiler team but factory 
initializers would be quite impactful not only for correctness for implementing 
swift-corelibs-foundation, performance for a number of cases as well as safety 
(I am certain we could remove some gnarly hacks in both the Foundation overlay 
and swift-corelibs-foundation if we could utilize factory pattern initializers)

> On Mar 17, 2017, at 4:26 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> Hi again everyone!
> 
> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
> be time to revisit this proposal and see if it might align with the goals set 
> forth for Swift 4.
> 
> As a quick tl;dr, this proposal describes a new "factory initializer" that 
> would allow you to return a value from an initializer. This would have 
> several benefits, as mentioned in the proposal itself as well as throughout 
> this mailing list. For convenience, here's a link to the proposal on GitHub: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> Would love to hear any more comments on this proposal, and if we feel this is 
> appropriate for considering for Swift 4 I'll happily re-open the pull request!
> 
> Riley Testut
> 
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  > wrote:
> 
>> i would appreciate this feature.
>> 
>> For unexperienced developers, its often hard to recognize *when* factory is 
>> a good fit to do the job, and how exactly approach the implementation. I 
>> imagine having this feature built into the language may help to choose and 
>> implement factory when its the right thing to do.
>> 
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> Is there any chance of reviving this? It seems to me that since this would 
>>> require Swift initializers to be implemented internally in such a way that 
>>> they can return a value (as Objective-C init methods do), it may affect ABI 
>>> stability and thus may be germane to the current stage of Swift 4 
>>> development.
>>> 
>>> Charles
>>> 
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 > wrote:
 
 Recently, I proposed the idea of adding the ability to implement the 
 "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
 discussed it and came up with different approaches, it evolved into a 
 functionality that I believe is far more beneficial to Swift, and 
 subsequently should be the focus of its own proposal. So here is the 
 improved (pre-)proposal:
 
 # Factory Initializers
 
 The "factory" pattern is common in many languages, including Objective-C. 
 Essentially, instead of initializing a type directly, a method is called 
 that returns an instance of the appropriate type determined by the input 
 parameters. Functionally this works well, but ultimately it forces the 
 client of the API to remember to call the factory method instead, rather 
 than the type's initializer. This might seem like a minor gripe, but given 
 that we want Swift to be as approachable as possible to new developers, I 
 think we can do better in this regard.
 
 Rather than have a separate factory method, I propose we build the factory 
 pattern right into Swift, by way of specialized “factory initializers”. 
 The exact syntax was proposed by Philippe Hausler from the previous 
 thread, and I think it is an excellent solution:
 
 class AbstractBase {
  public factory init(type: InformationToSwitchOn) {
  return ConcreteImplementation(type)
  }
 }
 
 class ConcreteImplementation : AbstractBase {
 
 }
 
 Why exactly would this be useful in practice? In my own development, I’ve 
 come across a few places where this would especially be relevant:
 
 ## Class Cluster/Abstract Classes
 This was the reasoning behind the original proposal, and I still think it 
 would be a very valid use case. The public superclass would declare all 
 the public methods, and could delegate off the specific implementations to 
 the private subclasses. Alternatively, this method could be used as an 
 easy way to handle backwards-compatibility: rather than litter the code 
 with branches depending on the OS version, simply return the 
 OS-appropriate subclass from the factory initializer. Very useful.
 
 ## Protocol 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Philippe Hausler via swift-evolution]

One point of concern with making the implementations rely on that: it would 
require any adopter of Codable to be built in swift 4 mode no? it might be 
valuable to keep the protocol not requiring Swift 4 to aide in incremental 
migration.

> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 16, 2017, at 4:12 PM, Itai Ferber > > wrote:
>> 
>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>> certainly consider it.
>> 
> Cool.  Any comment from the core team on whether this is a possibility?  If 
> it is and nobody else wants to write a proposal I would be willing to do it.
>> On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
>> 
>> 
>>> On Mar 16, 2017, at 3:01 PM, Itai Ferber >> > wrote:
>>> 
>>> Subscripts, by the way, would not help here, since they cannot throw. 
>>> decode must be able to throw.
>>> SR-238 
>>> ;
>>>  for Apple folks, 28775436.
>>> 
>> They don’t “help” but they do provide a more natural interface.  If the 
>> Foundation team feels a more wordy interface is necessary that is ok.
>> 
>> I specifically mentioned that they can’t throw yet.  Throwing subscripts 
>> would make a good companion proposal if they could fit into the Swift 4 
>> timeframe.  If not, then yes we need a method rather than a subscript.  But 
>> if we can get throwing subscripts into Swift 4, why not use Swift’s first 
>> class syntactic support for keyed access to keyed containers?
>> 
>>> On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:
>>> 
>>> 
>>> 
 On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution 
 > wrote:
 
 On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution 
 wrote:
> I don’t have an example but I don’t see a problem either.  There are two 
> options for specifying the return type manually.  We can use the 
> signature you used above and use `as` to specify the expected type:
> 
> let i = decode(.myKey) as Int
 
 The awkwardness of this syntax is exactly what I'm referring to. Would a 
 beginner know to use "as Int" or ": Int"? Why would they? The "prettiness" 
 of the simple case doesn't make up for how difficult it is to understand 
 and fix its failure cases.
 
 Any official Swift or Foundation API shouldn't, or shouldn't need to, make 
 use of "tricky" syntax.
>>> 
>>> I don’t think this is especially tricky.  Nevertheless, we can avoid 
>>> requiring this syntax by moving the type argument to the end and providing 
>>> a default.  But I think return type inference is worth supporting.  It has 
>>> become widely adopted by the community already in this use case.
>>> 
 
> If we don’t support this in Foundation we will continue to see 3rd party 
> libraries that do this.
 
 The proposal's been out for less than 24 hours, is it really productive to 
 already be taking our ball and go home over such a minor thing?
>>> 
>>> I don’t think that’s what I’m doing at all.  This is a fantastic proposal.  
>>> I’m still working through it and writing up my more detailed thoughts.
>>> 
>>> That said, as with many (most?) first drafts, there is room for 
>>> improvement.  I think it’s worth pointing out the syntax that many of us 
>>> would like to use for decoding and at least considering including it in the 
>>> proposal.  If the answer is that it’s trivial for those who want to use 
>>> subscripts to write the wrappers for return type inference and / or 
>>> subscripts themselves that’s ok.  But it’s a fair topic for discussion and 
>>> should at least be addressed as an alternative that was rejected for a 
>>> specific reason.
>>> 
 
 Zach Waldowski
 z...@waldowski.me 
 
 
 
 
 ___
 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 
>>> 
>> 
> 
> ___
> 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] Sequence/Collection Enhancements

[Philippe Hausler via swift-evolution]

I definitely find the intent here to be an interesting view at performant 
collection operations; in Foundation we have exposed IndexSet to do this type 
of thing.  When Foundation migrated to structural types it was really obvious 
to make IndexSet a structure - it was a logical change because it already was 
used as that concept in the Objective-C APIs. One of it’s biggest features is 
that it interoperates with NSArray/NSMutableArray which unfortunately it does 
not operate upon Array/Collection etc as of current. But there are APIs like 
UI/NS CollectionView that some of the primitive interoperation is based upon 
IndexSet which mirror NSArray/NSMutableArray making modeling really nice. As of 
current Swift is lacking some of those handy parallels. The IndexSet type has 
been used across many APIs in the SDK (as well as third party code). I wonder 
if it would be reasonable to sink an encapsulation type of the collection of 
ranges (as an efficient store) down and make it generic for the Index type. 
That way we would have a cohesive story when it comes to interoperation with 
on-going improvements that might happen in UIKit/AppKit/Foundation etc where 
the changes like this would interoperate well.

There are also a few other methods that I think might be worth investigating; 

non mutation
Fetching elements out of a collection given a sequence of ranges.
Fetching a sequence of ranges where a predicate matches elements (and perhaps 
even a sequence of ranges as a constraint upon that predicate)

mutation
Inserting a sequence of elements into the collection at indexes defined by a 
sequence of ranges
Replacing elements at indexes defined by a sequence of ranges with elements 
from a sequence

If we modified IndexSet to be generic (and perhaps moved it further down to 
interoperate with collection) I am certain that this would work really well 
with the already established APIs we have (just making bridged NSIndexSets 
really a IndexSet ). However this would mean that we would need some sort 
of way of indicating types were “Countable” which might be a decent addendum to 
the collection protocol cluster.


I think that overall these APIs have worked nicely with other counterparts 
(perhaps with a slight caveat of the matching of replacement counts and index 
counts). Additionally I am quite certain that having an encapsulating efficient 
storage for a sequence of ranges can allow for some really nice performance 
improvements and getting the performance point right is not always easy or 
obvious; so having the higher level APIs to handle these can not only be easier 
for the developer but also offer some really great performance optimizations 
too.

I have already tinkered with the idea of using IndexSet on Data and it is 
amazing; I can easily write really complex parsers for doing awful things like 
parsing mach-o headers from executables or other such things. I have also 
tinkered with the idea of making a slice type that is a sparse slice (it breaks 
some other assumptions of how collections work) and that works pretty nicely 
too (I think that should be a further discussion and this is probably not the 
time to introduce that idea just yet).

Hope that gives somethings to chew on from a frameworks perspective.

Cheers!
Philippe Hausler

> On Feb 16, 2017, at 4:39 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
> a thread to discuss additive algorithms for Sequence and Collection.
> 
> Here is a list of commonly requested algorithms to operate on Sequence or 
> Collection:
> 
> In-place transformations:
> transform elements in a MutableCollection using a closure i.e. in-place map
> remove(where:) that takes a predicate i.e. in-place filter
> remove(indices:) that takes a Sequence of Index
> bulk operations (replace, remove, insert) on RangeReplaceableCollection for a 
> Sequence of subranges
> Sorting:
> change sort/sorted/partition to be stable
> possibly add an explicitly unstable sort
> provide partial sorting i.e. the _n_th lowest element of a sequence
> Select a random element of a RandomAccessCollection (note this could include 
> a random element of 0.. Check if all elements in a Sequence match a predicate (i.e. 
> !contains(!predicate))
> reduce with an inout argument for the running value (PR for proposal here: 
> https://github.com/apple/swift-evolution/pull/587 
> )
> cycle – repeat a collection over and over.
> scan/accumulate/reductions/some other spelling of a reduce that returns the 
> running values (previously proposed: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>  
> )
> rotation of elements in a collection (deferred proposal: 
> 

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Philippe Hausler via swift-evolution]

The feature in this case I would claim is independent of the adopters. 
Personally I think this would be a useful feature to allow for better 
exposition into swift but also more robust objective-c APIs.

Something to consider here is that not all NSUIntegers can be NSNotFound, 
sometimes the return value is 0. It would be interesting to consider that 
_Nullable would be parameterized via a constant expression. This is a straw man 
refinement here (the exact spelling would be something we would have to audit 
the way it is implemented and likely use macros to compose the right 
nullability concepts)

Lets take for example this API:

+ (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream 
format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt 
error:(out NSError **)error;

The return value here would be 0 if an error occurs. So the nullability value 
would be 0.

+ (nullable(0) NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream 
*)stream format:(NSPropertyListFormat)format 
options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

But other APIs like you indicated:

- (NSUInteger)indexOfObject:(ObjectType)anObject;

Could be converted to:

- (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;

Which would immediately be an indication to the reader what the “null” value 
would be represented as. Of course your concept of type aliases might be a 
decent way to group concepts together but if lets say there was an index type 
for NSArray; obviously you might want a index return value to be nullable but 
it would be a bit confusing to take a nullable parameter into certain APIs.

Given a concept of NSArrayIndex as you suggested (that being nullable) would 
have the problem that 

- (ObjectType)objectAtIndex:(NSUInteger)index;

Would either incorrectly indicate it would be nullable or it would have a 
different type. 

There would be other cases where structural types might need a nullable 
placeholder value, e.g. NSRange with a location of NSNotFound and a length of 0 
(however that strictly isn’t correct since it is just the location that 
indicates null-ness.. but that is probably more of an implementation detail and 
should probably be corrected imho).

There could also be cases where an API returns either an object of a specific 
type or NSNull as a placeholder. This would be nice to be able to express as a 
nullable type especially in generics. For example: `NSArray<_Nullable(NSNull *) 
Foo *> *` could be a neat way to express `Array` which cannot be 
expressed currently.

Overall I think this could really reduce some of the overlays for all the 
frameworks on Mac OS X and iOS, improve the expressivity of Objective-C APIs, 
offer more accurate bridged representations, and generally give API authors an 
opportunity to more correctly represent what should be exposed in Swift without 
needing to write overlays that could easily have poor interaction with things 
like subclassing or delegation.

As a side note: I am not certain if the parameterization of nullability 
annotations would even be possible in the current compiler implementations or 
if it would be easier to use an attribute instead (that would be left to 
implementation detail).

I would guess that if this feature would be available it would take a combined 
effort from all API maintainers to annotate their return values and any 
un-annotated shouldn’t be exposed as a IOU since they have non nil values 
already. Furthermore the timeframe to do so would probably be independent of 
the implementation of this type of feature. 

Those caveats aside - I think it would be a fantastic tool in the toolbox!

> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown  > wrote:
> I think the biggest problem we're going to face with this one is changes to 
> Objective-C are out of scope for Swift Evolution. Apple tend to be the ones 
> in control of the development of new Objective-C features and compatibility 
> because they control the compiler.
> 
> I don’t think that Objective-C changes are out of bounds when Swift is 
> involved—see my past, accepted proposal at SE-0033 
> .
>  
> That said, as a request to Apple for this change, I think it's a reasonable 
> idea for Ints, but I'm not sure of its feasibility for other types. Could the 
> API be descriptive enough to cover enough types? (Eg CGRectNull)
> 
> It’s an open-and-shut case for any standard primitive, but structs like 
> CGRect are where it starts to get tricky. I see that CGRect conforms to 
> Equatable when it’s imported into Swift; perhaps that could be enough for 
> this to work? If the translation to and from nil happens in the Swift side, I 
> can see Equatable 

Re: [swift-evolution] Make UUID conform to RawRepresentable

[Philippe Hausler via swift-evolution]

RawRepresentable is often used for open enums imported from c/objc so I am not 
certain that is the right semantics.

Sent from my iPhone

> On Jun 21, 2016, at 1:19 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 21 Jun 2016, at 01:53, Alsey Miller via swift-evolution 
>>  wrote:
>> 
>> I’m the developer of PureSwift/SwiftFoundation on GitHub, and I originally 
>> wrote that library after WWDC 2015 because I did not expect Apple to release 
>> an Open Source version of Foundation, and also because Foundation in Swift 
>> 2.2 was class based, and not struct based. Now in Swift 3 that is all 
>> changing (for the better), and I plan to deprecate my library, but there is 
>> one semantic that takes advantage of the Swift guidelines that the new Swift 
>> 3.0 Foundation in Xcode 8 doesn’t. UUID seems a natural candidate for 
>> conforming to RawRepresentable. Please check out the link below, and you can 
>> see how it naturally fits.
>> 
>> https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/UUID.swift
> 
> Your library uses RawRepresentable for String conversion, but 
> LosslessStringConvertible (if SE-0089 is accepted) could also do this.
> 
> Then the RawRepresentable.RawValue could be `uuid_t` (equivalent to your 
> ByteValue tuple) instead.
> 
> NOTE: 
> 
> 
> -- Ben
> 
> ___
> 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-0089: Renaming String.init(_: T)

[Philippe Hausler via swift-evolution]

> On May 17, 2016, at 8:32 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
> through May 23. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

This method definitely has some strange behavior and I think it most certainly 
would benefit from a better name. `init(printing value:)` to me sounds 
like this is somehow printing the string, either to the console or to an arcane 
device called a “printer”. Personally I think that  `init(describing 
value:)` is more suitable as a name of an initializer.

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

Absolutely! It improves safety and clarity with little cost to developers

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

Most definitely

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

I have never run across this issue in another language/library. However I have 
previously attempted to avoid similar problems in C++ so I would definitely 
consider the standard of having good (and un-ambiguous names a strong benefit 
when it comes to potentially too generic methods)

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

I have personally run across bugs due to this in the wild and it definitely was 
unexpected and probably took me too long to recognize the reason on why it 
happened.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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-0086: Drop NS Prefix in Swift Foundation

[Philippe Hausler via swift-evolution]

> On May 10, 2016, at 12:48 PM, Philippe Hausler via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/
>> 0086-drop-foundation-ns.md>
>> 
>> +1 to dropping the NS prefix; type names are more readable. However:
>> 
>> * AppKit, CoreData, and TextKit will still use the NS prefix.
>> * Prefixed names (in all frameworks) are more "googleable".
>> * Should deprecated types (e.g. NSMessagePort) keep the prefix?
>> 
>> +1 to using nested enums/options; it will make method signatures shorter.
>> 
>> You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
>> move your experimental `scheduledTimer` method to the RunLoop class.
>> 
>> Will top-level constants/functions also be nested? For example:
>> 
>> * SE-0033: Import Objective-C Constants as Swift Types
>> * SE-0044: Import as Member
>> 
>> Missing from the "Drop NS prefix" list:
>> 
>> * NSBinarySearchingOptions

More corrections: this will drop it’s NS

>> * NSCopying, NSMutableCopying
> 
> The reasoning behind these keeping NS is that almost all of the mutable 
> copying items have a correlative structural type; e.g. Data, Array, 
> Dictionary, Set etc.
> 
>> * NSDirectoryEnumerator
> 
> NSDirectoryEnumerator is going to be hoisted into 
> FileManager.DirectoryEnumerator (I think the proposal may have missed this 
> one)
> 
>> * NSEnumerationOptions

As will this.

>> * NSEnumerator
> 
> NSEnumerator is used to enumerate the NS collections of references
> 
>> * NSExpression
> 
> This is very tied to KVC and reference collections
> 
>> * NSNull
> 
> Not really applicable in swift since you can have an array of options etc.
> 
>> * NSSecureCoding

This was an oversight and should have it’s prefix dropped as well.

>> * NSSortOptions

NSSortOptions  also will shed it’s prefix

>> 
>> Missing from the "Hoisted types" list:
>> 
>> * NSAffineTransformStruct
> 
> This one is actually being renamed a bit differently; it will be called 
> AffineTransform to the counterpart reference type NSAffineTransform
> 
>> * NSDateComponentsFormatterUnitsStyle
> 
> This is missing from the proposal and should be listed as 
> DateComponentsFormatter.UnitsStyle
> 
>> * NSDateComponentsFormatterZeroFormattingBehavior
> 
> This is missing from the proposal and should be listed as 
> DateComponentsFormatter.ZeroFormattingBehavior
> 
>> * NSRoundingMode
> 
> This is missing from the proposal and should be listed as Decimal.RoundingMode
> 
>> 
>> -- Ben
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> The others I need to follow up on with Tony to determine if they need better 
> refinements.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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-0086: Drop NS Prefix in Swift Foundation

[Philippe Hausler via swift-evolution]

> On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
>  0086-drop-foundation-ns.md>
> 
> +1 to dropping the NS prefix; type names are more readable. However:
> 
> * AppKit, CoreData, and TextKit will still use the NS prefix.
> * Prefixed names (in all frameworks) are more "googleable".
> * Should deprecated types (e.g. NSMessagePort) keep the prefix?
> 
> +1 to using nested enums/options; it will make method signatures shorter.
> 
> You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
> move your experimental `scheduledTimer` method to the RunLoop class.
> 
> Will top-level constants/functions also be nested? For example:
> 
> * SE-0033: Import Objective-C Constants as Swift Types
> * SE-0044: Import as Member
> 
> Missing from the "Drop NS prefix" list:
> 
> * NSBinarySearchingOptions
> * NSCopying, NSMutableCopying

The reasoning behind these keeping NS is that almost all of the mutable copying 
items have a correlative structural type; e.g. Data, Array, Dictionary, Set etc.

> * NSDirectoryEnumerator

NSDirectoryEnumerator is going to be hoisted into 
FileManager.DirectoryEnumerator (I think the proposal may have missed this one)

> * NSEnumerationOptions
> * NSEnumerator

NSEnumerator is used to enumerate the NS collections of references

> * NSExpression

This is very tied to KVC and reference collections

> * NSNull

Not really applicable in swift since you can have an array of options etc.

> * NSSecureCoding
> * NSSortOptions
> 
> Missing from the "Hoisted types" list:
> 
> * NSAffineTransformStruct

This one is actually being renamed a bit differently; it will be called 
AffineTransform to the counterpart reference type NSAffineTransform

> * NSDateComponentsFormatterUnitsStyle

This is missing from the proposal and should be listed as 
DateComponentsFormatter.UnitsStyle

> * NSDateComponentsFormatterZeroFormattingBehavior

This is missing from the proposal and should be listed as 
DateComponentsFormatter.ZeroFormattingBehavior

> * NSRoundingMode

This is missing from the proposal and should be listed as Decimal.RoundingMode

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

The others I need to follow up on with Tony to determine if they need better 
refinements.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0069: Mutability and Foundation Value Types

[Philippe Hausler via swift-evolution]

I haven't tried to directly replace them yet but I would imagine that in order 
to replicate behavior some of the reference types will still be needed. That 
being said, other classes may no longer have any real value (not fully intended 
to be a pun) since types like NSDate are just simple wrappers around a simple 
value type. There will be a few parts: like coding or property lists that will 
still need to internally require a reference type to manipulate in CF code.

The boxing types will be simpler than the overlay for Objective-C since the 
corelibs version are all Swift classes at their base.

In short I think it would be best to just add and not remove things for now 
from swift-corelibs-foundation when modifications are made to bring these in 
sync. 

Sent from my iPhone

> On Apr 25, 2016, at 8:35 PM, David Waite via swift-evolution 
>  wrote:
> 
> Comments:
> 
> - The sentences "These new struct types will be implemented in the Swift 
> overlay. Immutable/mutable pairs (e.g. Data and MutableData) will become one 
> mutable struct type” are a duplicate and may be a copy/paste error.
> 
> - I am unsure when a new struct type contains a mutable or immutable boxed 
> object. 
> 
> - Is there a goal to eventually replace/remove the NS* versions completely 
> within corelibs-foundation?
> 
> -DW
> 
>> On Apr 25, 2016, at 4:21 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> Enormous +1.  This is a no-brainier IMO.  I am really happy to see this 
>> being tackled in the Swift 3 timeframe.
>> 
>> Sent from my iPad
>> 
>>> On Apr 25, 2016, at 12:27 PM, Chris Lattner  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0069: Mutability and Foundation Value Types" begins now 
>>> and runs through May 4. The proposal is available here:
>>> 
>>>   
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>>   https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>>   * What is your evaluation of the proposal?
>>>   * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>>   * Does this proposal fit well with the feel and direction of Swift?
>>>   * If you have you 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?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>>   https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mutability for Foundation types in Swift

[Philippe Hausler via swift-evolution]

> On Apr 22, 2016, at 2:36 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> One comment:
> 
> "In the most common case where a developer does not provide a custom 
> reference type, then the backing store is our existing NSData and 
> NSMutableData implementations. This consolidates logic into one place and 
> provides cheap bridging in many cases (see Bridging for more information).”
> 
> Would it not be more efficient to bridge to the C-based CFData and 
> CFMutableData implementations instead, to avoid the object overhead?

Actually it is often the case that the NS counterparts are faster than the CF 
versions (data being one of them).

> 
> Charles
> 
>> On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution 
>>  wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this particular change to the swift-evolution list.
>> 
>> As always I welcome your feedback.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] Mutability for Foundation types in Swift

[Philippe Hausler via swift-evolution]

> On Apr 22, 2016, at 1:53 PM, plx via swift-evolution 
>  wrote:
> 
> On the one hand I like the idea (and particularly like the foundation types 
> having meaningful `mutating` annotations, loosely speaking).
> 
> On the other hand I have two questions:
> 
> 1. will the NS types actually remain visible/usable (on supported platforms, 
> perhaps requiring a specific import to become visible)?

NSData will still exist and be available (as will NSMutableData) on all 
platforms including swift-corelibs versions; there are still some reasons to 
have reference semantics from time to time hence why the proposal did not take 
away any of them.

> 2. does this include — or are their separate plans for — exposing the backing 
> reference type in some principled way? 

`as` cast will grant a reference type, but of course this has a potential of a 
copy semantic. A direct access to the underlying box that contains the object 
would be dangerous; in that references passed around for that container would 
be beyond the scope of data’s control (Tony might be able to speak on this a 
bit more than myself)

The structure may later drop it’s reference to that object and construct a new 
version upon mutation etc.

> 
> For (2.) what I mean is something like having at least the heavyweight thing 
> like `Data` (and ideally also Array/Set/Dictionary/IndexSet, etc.) have 
> matching-API reference types like `DataRef` in the standard library. 


let dataStructure = Data(bytes: someBytes, count: 5)
let dataReference = dataStructure as NSData // this is a reference version of 
the structural container, but you should not count on the identity since the 
structure could mutate out and replace the backing storage.

> 
> I think this has come up before at some point, but if it did I didn’t follow 
> it.
> 
> My interest in (1.) is mostly b/c I suspect the answer to (2.) is “no”.
> 
> Apologies if these are alrexdy-addressedd and I just missed it.
> 
>> On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution 
>> > wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this particular change to the swift-evolution list.
>> 
>> As always I welcome your feedback.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> 
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> ___
>> 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