[swift-users] WWDC Meetup

[David Hart via swift-users]

I imagine that during WWDC a non-negligible proportion of the Swift Open Source 
contributors will be in or around San-Francisco. I’d very much like to profit 
from that opportunity to meet-up, get to know each other, talk Swift over some 
beers! Is anybody interested? If yes, any ideas for location? I can setup a 
Doodle once I see enough interest.

Looking forward to meet you!___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] WWDC Meetup

[David Hart via swift-users]

I imagine that during WWDC a non-negligible proportion of the Swift Open Source 
contributors will be in or around San-Francisco. I’d very much like to profit 
from that opportunity to meet-up, get to know each other, talk Swift over some 
beers! Is anybody interested? If yes, any ideas for location? I can setup a 
Doodle once I see enough interest.

Looking forward to meet you!___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-corelibs-dev] [swift-evolution] WWDC Meetup

[David Hart via swift-users]

Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
proposing dinner somewhere.

I’ve setup a Google Forms to help organise it:

http://goo.gl/forms/Oq6dK9fPNSCAVfL72 

> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>  wrote:
> 
> +1 to both points :)
> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
> mailto:swift-corelibs-...@swift.org>> wrote:
> I would love to join as well!!
> 
> I'd like to propose perhaps to plan something alternative to beers to keep it 
> inclusive to members who may not be 21 or like to drink alcohol :)
> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
> mailto:swift-evolut...@swift.org>> wrote:
> +1  I'd love to put some faces to some names  :)  sounds fun!
> 
> Shane
> 
> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users  > wrote:
> 
>> I'd be interested in catching up. Was curious if there was going to be a 
>> meet up, either formal or informal. Sounds good.
>> 
>> -Rod
>> 
>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> 
>>> I imagine that during WWDC a non-negligible proportion of the Swift Open 
>>> Source contributors will be in or around San-Francisco. I’d very much like 
>>> to profit from that opportunity to meet-up, get to know each other, talk 
>>> Swift over some beers! Is anybody interested? If yes, any ideas for 
>>> location? I can setup a Doodle once I see enough interest.
>>> 
>>> Looking forward to meet you!
>>> ___
>>> swift-evolution mailing list
>>> swift-evolut...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> 
>> ___
> 
>> 
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> -- 
> Javier Soto
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-users] [swift-evolution] [swift-corelibs-dev] WWDC Meetup

[David Hart via swift-users]

Hi everybody,

After receiving a private question, I'd like to clarify something: I’m hoping 
that anybody interested in the Swift Open Source project, contributor or not, 
WWDC ticket holder or not, should feel free to come! This is definitely not 
something I meant to be restricted in any way. My original wording wasn’t 
entirely clear.

So, if you like Swift, if you have an interest in discussing about the Open 
Source project, please feel welcome to subscribe!

David.

> On 07 Jun 2016, at 08:46, David Hart via swift-evolution 
>  wrote:
> 
> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
> proposing dinner somewhere.
> 
> I’ve setup a Google Forms to help organise it:
> 
> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 
> 
>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>> mailto:swift-corelibs-...@swift.org>> wrote:
>> 
>> +1 to both points :)
>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>> mailto:swift-corelibs-...@swift.org>> wrote:
>> I would love to join as well!!
>> 
>> I'd like to propose perhaps to plan something alternative to beers to keep 
>> it inclusive to members who may not be 21 or like to drink alcohol :)
>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> +1  I'd love to put some faces to some names  :)  sounds fun!
>> 
>> Shane
>> 
>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users > > wrote:
>> 
>>> I'd be interested in catching up. Was curious if there was going to be a 
>>> meet up, either formal or informal. Sounds good.
>>> 
>>> -Rod
>>> 
>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> 
 I imagine that during WWDC a non-negligible proportion of the Swift Open 
 Source contributors will be in or around San-Francisco. I’d very much like 
 to profit from that opportunity to meet-up, get to know each other, talk 
 Swift over some beers! Is anybody interested? If yes, any ideas for 
 location? I can setup a Doodle once I see enough interest.
 
 Looking forward to meet you!
 ___
 swift-evolution mailing list
 swift-evolut...@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> 
>>> ___
>> 
>>> 
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> -- 
>> Javier Soto
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-users] [swift-corelibs-dev] [swift-evolution] WWDC Meetup

[David Hart via swift-users]

Thanks for everybody that took the time to fill the form! There were many more 
responses than I expected, so dinner becomes difficult to organise. But thanks 
to a hand from another community member, we should have a venue confirmed soon.

We are currently shooting for Tuesday evening.

More details coming ASAP.

> On 07 Jun 2016, at 08:46, David Hart  wrote:
> 
> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
> proposing dinner somewhere.
> 
> I’ve setup a Google Forms to help organise it:
> 
> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 
> 
>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>> mailto:swift-corelibs-...@swift.org>> wrote:
>> 
>> +1 to both points :)
>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>> mailto:swift-corelibs-...@swift.org>> wrote:
>> I would love to join as well!!
>> 
>> I'd like to propose perhaps to plan something alternative to beers to keep 
>> it inclusive to members who may not be 21 or like to drink alcohol :)
>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> +1  I'd love to put some faces to some names  :)  sounds fun!
>> 
>> Shane
>> 
>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users > > wrote:
>> 
>>> I'd be interested in catching up. Was curious if there was going to be a 
>>> meet up, either formal or informal. Sounds good.
>>> 
>>> -Rod
>>> 
>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> 
 I imagine that during WWDC a non-negligible proportion of the Swift Open 
 Source contributors will be in or around San-Francisco. I’d very much like 
 to profit from that opportunity to meet-up, get to know each other, talk 
 Swift over some beers! Is anybody interested? If yes, any ideas for 
 location? I can setup a Doodle once I see enough interest.
 
 Looking forward to meet you!
 ___
 swift-evolution mailing list
 swift-evolut...@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> 
>>> ___
>> 
>>> 
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> -- 
>> Javier Soto
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

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

Re: [swift-users] [swift-corelibs-dev] [swift-evolution] WWDC Meetup

[David Hart via swift-users]

Hi all,
 
I have some news on the WWDC meet-up that was announced earlier this week. 
Thanks to the help of a friendly community member, Bert Belder, we have been 
able to secure a very cool venue!

The meetup will take place on Tuesday, June 14th at 7pm, in the IBM Bluemix 
Garage, which is at about 5 minutes walking distance from the Moscone Center. 
So WWDC visitors should have no problem getting there.
The full address is: 543 Howard st, San Francisco. 
https://goo.gl/maps/2EqAN4eNEu72 
We’ll make sure there are some bites and drinks so you don’t have to worry 
about your  basic human needs.
 
Our goal is to create a small and social event where people involved in the 
Swift open source community can meet each other face-to-face. Some folks from 
IBM that work on Swift for Linux and the package catalog will be there. If you 
know of others involved in the swift open-source ecosystem, feel free to invite 
them.
 
Please RSVP at https://ti.to/swift-oss/wwdc-2016 
. It’s free, we just need to know how many 
people are coming. We currently have a limit of 50 people.

Although we want to make this mostly a social event, there will be some room 
for short presentations. If you can talk for 5 minutes about your Swift pet 
project, we’d love to hear it.

That’s all for now - hope to see you next week!

David & Bert

> On 08 Jun 2016, at 08:10, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Thanks for everybody that took the time to fill the form! There were many 
> more responses than I expected, so dinner becomes difficult to organise. But 
> thanks to a hand from another community member, we should have a venue 
> confirmed soon.
> 
> We are currently shooting for Tuesday evening.
> 
> More details coming ASAP.
> 
>> On 07 Jun 2016, at 08:46, David Hart > > wrote:
>> 
>> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
>> proposing dinner somewhere.
>> 
>> I’ve setup a Google Forms to help organise it:
>> 
>> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 
>> 
>>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>>> mailto:swift-corelibs-...@swift.org>> wrote:
>>> 
>>> +1 to both points :)
>>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>>> mailto:swift-corelibs-...@swift.org>> wrote:
>>> I would love to join as well!!
>>> 
>>> I'd like to propose perhaps to plan something alternative to beers to keep 
>>> it inclusive to members who may not be 21 or like to drink alcohol :)
>>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> +1  I'd love to put some faces to some names  :)  sounds fun!
>>> 
>>> Shane
>>> 
>>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
 I'd be interested in catching up. Was curious if there was going to be a 
 meet up, either formal or informal. Sounds good.
 
 -Rod
 
 On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
 mailto:swift-evolut...@swift.org>> wrote:
 
> I imagine that during WWDC a non-negligible proportion of the Swift Open 
> Source contributors will be in or around San-Francisco. I’d very much 
> like to profit from that opportunity to meet-up, get to know each other, 
> talk Swift over some beers! Is anybody interested? If yes, any ideas for 
> location? I can setup a Doodle once I see enough interest.
> 
> Looking forward to meet you!
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
>>> 
 ___
>>> 
 
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolut...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> -- 
>>> Javier Soto
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 

Re: [swift-users] try? works on non-method-call?

[David Hart via swift-users]

I think that on error or warning like this is the right solution.

> On 21 Jul 2016, at 08:13, Sikhapol Saijit via swift-users 
>  wrote:
> 
> 1. Is it intentional that `try?` can be used with non-method-call and return 
> an optional of the type that follows?

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

Re: [swift-users] What's the relationship between Swift Package Manager and Xcode?

[David Hart via swift-users]

If you are only building application bundles for Darwin platforms, have no 
interest in server Swift, you don’t *need* to look into SPM for now. But as its 
going to be part of Xcode soon, and if you want to help shape into something 
you would be interested it, its always worth looking at it now.

> On 02 Aug 2016, at 14:24, zh ao  wrote:
> 
> I have these questions because I saw SPM can build executables as well. I am 
> wondering if I could benefit from learning SPM now or I should leave it alone.
> 
> It seems that those questions are too early to ask for one who is solely 
> using Xcode.
> 
> Zhaoxin 
> 
> Get Outlook for iOS 
> 
> 
> 
> On Tue, Aug 2, 2016 at 8:15 PM +0800, "David Hart"  > wrote:
> 
> I don't know what you mean by packaging. Xcode has been build 
> responsibilities, including many which SPM does not currently address and may 
> never will: building application bundles for Apple platforms, building 
> resource bundles, building Darwin frameworks (I'm fairly sure SPM currently 
> only builds simple libraries).
> 
> On the topic of what Xcode will become, this is not the place to discuss it. 
> And I'm fairly sure you won't get any specifics from the Xcode team as it's 
> still under Apple's umbrella of secrecy. The only thing we know or can guess 
> is that it will get some sort of SPM integration.
> 
> On 2 Aug 2016, at 13:54, Zhao Xin via swift-users  > wrote:
> 
>> ​Is Swift Package Manager, SPM, the competitor to Xcode packaging? Or is it 
>> the future of Xcode packing? If it is, when will it be put into Xcode?
>> 
>> Also, what are the differences between built packages and Apple provided 
>> frameworks? Are they just the same thing with different names?
>> 
>> Zhaoxin
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 

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

Re: [swift-users] Regression in Xcode8-beta6 Swift?

[David Hart via swift-users]

You can’t call arbitrary functions on AnyObject anymore. Previously, you could 
do this:

let a: AnyObject = UIView()
a.hasPrefix(“test”) // This compiled (because hasPrefix(:_) exists on 
NSString), but would obviously crash

This is not allowed anymore.

> On 25 Aug 2016, at 03:33, Travis Griggs via swift-users 
>  wrote:
> 
> Upgrading to beta6 of Xcode8, I’ve read through various SE’s and made fixes 
> as appropriate, but the following behavior I didn’t catch an explanation as 
> to why its now an error where it was fine before.
> 
> In a ViewController, I have something that looks like:
> 
>var addButton = UIButton(type: .custom)
>var addPrompt = UILabel()
>var timesButton = UIButton(type: .system)
>var removeButton = UIButton(type: .system)
>var menuButton = UIButton(type: .system)
>   
>func commonInit() {
>[self.addButton, self.addPrompt, self.timesButton, self.removeButton, 
> self.menuButton].forEach { control in
>control.sizeToFit()
>self.addSubview(control)
>}
> 
> This code was fine until the latest update. It seemed to a heterogenous array 
> of UILabel and UIButtons was a homogeneous array of UIView objects. But now I 
> get the errors:
> 
>Value of type ‘Any’ has no member ‘sizeToFit'
>Cannot covert value of type ‘Any’ to expected argument type of ‘UIView’
> 
> This seems like it might be related to SE-0116 (Import Objective-C id as 
> Swift Any ) but I’m not sure why the inferencer can no longer find the shared 
> parent type, where it could before.
> 
> Aside, I can fix it by simply helping it a little, e.g.
> 
>[self.addButton, self.addPrompt, self.timesButton, self.removeButton, 
> self.menuButton].forEach { (control:UIView) in...
> 
> But remain curious why the inferencer can’t handle this for me anymore.
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Regression in Xcode8-beta6 Swift?

[David Hart via swift-users]

That proposal also says:
Deciding the fate of AnyObject lookup

We currently bestow the AnyObject existential type with the special ability to 
look up any @objc method dynamically, in order to ensure id-based ObjC APIs 
remain fluent when used in Swift. This is another special, unprincipled, 
nonportable feature that relies on the Objective-C runtime. If we change  id to 
bridge to Any, it definitely no longer makes sense to apply to AnyObject. A 
couple of possibilities to consider:

We could transfer the existing AnyObject behavior verbatim to Any.
We could attempt to eliminate the behavior as a language feature. An 
approximation of AnyObject's magic behavior can be made using operators and 
unapplied method references, in a way that also works for Swift types:

  /// Dynamically dispatch a method on Any.
  func => (myself: Any, method: (T) -> V) -> V? {
if let myself = myself as? T {
  return method(myself)
}
return nil
  }
though that's not quite the right thing for id lookup, since you want a 
respondsToSelector rather than isKindOfClass check.

We could narrow the scope of the behavior. Jordan has suggested allowing only 
property and subscript lookup off of AnyObject or Any, as a way of allowing 
easy navigation of property lists, one of the most common sources of id in 
Foundation.
If we're confident that the SDK will be sufficiently Swiftified that ids become 
relatively rare, maybe we could get away without a replacement at all.
What was decided concerning that? I felt sure that the lookup had been 
completely removed, but I’m obviously mistaken.

David.


> On 25 Aug 2016, at 09:59, Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 25 Aug 2016, at 08:23, David Hart via swift-users  
> wrote:
> 
>> You can’t call arbitrary functions on AnyObject anymore.
> 
> You’re mixing up `Any` and `AnyObject`.  You can still call arbitrary methods 
> on `AnyObject`, as Martin demonstrated, but Travis’s error message referenced 
> `Any`.
> 
> SE-0116 [1] means that `Any` is a lot more common these days.
> 
> Notwithstanding the above, I don’t have any input on the change of behaviour 
> Travis is seeing.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"<http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> [1] 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md>
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Regression in Xcode8-beta6 Swift?

[David Hart via swift-users]

I misunderstood the release notes for Xcode 8 beta 6 I read a few days ago. 
Here what will interest you:

Since ‘id’ now imports as ‘Any’ rather than ‘AnyObject’, you may see errors 
where you were previously performing dynamic lookup on ‘AnyObject’. For example 
in:

  guard let fileEnumerator = FileManager.default.enumerator(atPath: path)
  else {
return }

  for fileName in fileEnumerator {
  if fileName.hasSuffix(".txt") {
  // error: value of type ‘Element’ (aka ‘Any’) has no member
  hasSuffix
  print(fileName)
  }
}
The fix is to either cast to AnyObject explicitly before doing the dynamic 
lookup, or force cast to a

specific object type:

  guard let fileEnumerator = FileManager.default.enumerator(atPath: path)
  else {
return }

  for fileName in fileEnumerator {
  if (fileName as AnyObject).hasSuffix(".txt") {
  // cast to AnyObject
  print(fileName)
  }
}

(27639935) 



> On 25 Aug 2016, at 10:32, Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 25 Aug 2016, at 09:27, David Hart  wrote:
> 
>> That proposal also says:
> 
> Indeed.  Good point.
> 
>> What was decided concerning that?
> 
> I don’t know, although given that that text was from the “Future Directions” 
> section it seems like that nothing has changed yet.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Performance critical code in Swift

[David Hart via swift-users]

That fact that Realm has an ORM layer, and that batch inserts are noticeably 
slower than in SQLite makes it less performant in certain scenarios. The fact 
that is does not support JOIN queries also causes issues in other performance 
scenarios.

> On 2 Oct 2016, at 20:26, Marco S Hyman via swift-users 
>  wrote:
> 
>> 
>> On a broader note, I have yet to see a true modern replacement for SQLite on 
>> the embedded side. There are any number of lightweight document stores, but 
>> they either have performance worse than SQLite, or are not really suitable 
>> for embedded use.
> 
> Realm ???
> 
> It’s faster than sqlite and easy to use.  At least I found it easy in a 
> simple swift test app I wrote a while back.   Haven’t played with it since 
> the switch to swift 3.0.
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] How to be DRY on ranges and closed ranges?

[David Hart via swift-users]

I’ve been bitten by that quite a few times. I’m not a fan of the new 
distinction between Range and ClosedRange. I understand the reasoning behind 
them, but the new model is creating more problems for me than the it solves.

David.

> On 12 Oct 2016, at 12:21, Jean-Denis Muys via swift-users 
>  wrote:
> 
> Hi,
> 
> I defined this:
> 
> func random(from r: Range) -> Int {
> let from = r.lowerBound
> let to =  r.upperBound
> 
> let rnd = arc4random_uniform(UInt32(to-from))
> return from + Int(rnd)
> }
> 
> so that I can do:
> 
> let testRandomValue = random(from: 4..<8)
> 
> But this will not let me do:
> 
> let otherTestRandomValue = random(from: 4...10)
> 
> The error message is a bit cryptic:
> 
> “No ‘…’ candidate produce the expected contextual result type ‘Range’”
> 
> What is happening is that 4…10 is not a Range, but a ClosedRange.
> 
> Of course I can overload my function above to add a version that takes a 
> ClosedRange.
> 
> But this is not very DRY.
> 
> What would be a more idiomatic way?
> 
> Thanks,
> 
> Jean-Denis
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] find std lib doc

[David Hart via swift-users]

Dash + Alfred :)

> On 12 Oct 2016, at 17:13, Lars-Jørgen Kristiansen via swift-users 
>  wrote:
> 
> I recommend Dash 😏
> 
>> 12. okt. 2016 kl. 17.03 skrev Adrian Zubarev via swift-users 
>> mailto:swift-users@swift.org>>:
>> 
>> You could also fallback to http://swiftdoc.org . ;)
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. Oktober 2016 um 17:01:48, Jon Shier via swift-users 
>> (swift-users@swift.org ) schrieb:
>> 
>>> I’m guessing you only came to Apple’s developer environment with Swift? (If 
>>> not I apologize.) The searchability and discoverability of anything on 
>>> Apple’s dev site is rather low. You learn to live with it and use Google 
>>> whenever you need to find something. (Which turns up the standard library 
>>> docs as the first result if you search for “swift standard library 
>>> documentation”). 
>>> 
>>> 
>>> 
>>> Jon
>>> 
 On Oct 12, 2016, at 7:58 AM, J.E. Schotsman via swift-users 
 mailto:swift-users@swift.org>> wrote:
 
 
> On 12 Oct 2016, at 13:31, Adrian Zubarev  > wrote:
> 
> It’s not hidden.
> 
> https://developer.apple.com/ 
> Develop
> API Reference
> Swift Standard Library
> Profit https://developer.apple.com/reference/swift 
> I see. I still find it 
> strange that it cannot be found on developer.apple.com 
>  with the search function.
 The swift.org  version used to have a nice display of 
 the hierarchical arrangement of protocols. Is that still available 
 anywhere?
 
 Jan E.
 ___
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[David Hart via swift-users]

I think we need a warning because it is definitely ambiguous and a common 
pitfall for users of an API. The only solution would be for the APIs be written 
so to avoid those ambiguities I think.

> On 5 Jan 2017, at 08:58, Rien via swift-users  wrote:
> 
> As you know. there is no ambiguity, no warnings needed.
> (The parameter is part of the identifier of the function)
> 
> Imo, this request falls into the category “do as I think, not as I say”.
> 
> That is a discussion without end. Personally I am against ANY warnings of 
> this kind. The reason is that I want my code to compile warnings free 
> (default compiler behaviour) and I do not want an extra pragma in the code to 
> instruct the compiler that when I am calling “foo()” I do indeed want to call 
> “foo()”.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>  wrote:
>> 
>> Hello,
>> 
>> I wasn’t sure whether to post this message here, at swift-dev, or at 
>> swift-evolution. so I’ll try here first. Hopefully it will get to the right 
>> group of people or, if not, someone will point me to the right mailing list.
>> 
>> I came across a situation that boils down to this example:
>> 
>> class Parent {
>>   func foo() {
>>   print("Parent foo() called")
>>   }
>> }
>> 
>> class Child: Parent {
>>   func foo(x: Int = 0) {
>>   print("Child foo() called")
>>   }
>> }
>> 
>> let c = Child()
>> c.foo()  // prints "Parent foo() called"
>> 
>> I understand why this behaves like so, namely, the subclass has a method 
>> foo(x:) but no direct implementation of foo() so the parent’s implementation 
>> is invoked rather than the child's. That’s all fine except that it is not 
>> very intuitive.
>> 
>> I would argue that the expectation is that the search for an implementation 
>> should start with the subclass (which is does) but should look at all 
>> possible restrictions of parent implementations, including the restriction 
>> due to default values.
>> 
>> At the very least, I think the compiler should emit a warning or possibly 
>> even an error.
>> 
>> Thanks for reading.
>> Cheers,
>> 
>> Wagner
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[David Hart via swift-users]

Hi Ted,

Thanks so much for taking time to discuss this with the team. I feel very 
confident this is going to be a big plus for the community :)

David

> On 9 Feb 2017, at 01:03, Ted kremenek via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> There was a long thread on swift-evolution about whether we should use modern 
> forum software — like Discourse — as an alternative to the mailing lists we 
> have now.  After a long discussion, the Core Team has decided to move 
> swift-evolution and swift-users to Discourse.
> 
> There are tradeoffs to moving to a forum.  The main advantages are:
> 
> - Easy for people to participate without subscribing to the entire mailing 
> list, as well as no need to provide email address to participate.  A lot of 
> people have voiced concern that they feel resistance to participate because 
> of needing to subscribe to a mailing list.
> 
> - Consistent affordances and rendering of content, including Markdown 
> support.  This is really useful for having technical discussions.
> 
> - Better searching of topics, archiving, etc.
> 
> - More tools for moderation.
> 
> - Topic cross-referencing, and consistent organization of topics instead of 
> whatever threading support a mail client provides (which is inconsistent).
> 
> I also want to consider moving the -dev lists to the same forum setup as 
> well; but that will be a separate conversation on those lists.
> 
> A rollout plan has not been figured out.  People are busy and there are 
> logistics to figure out.  I will be engaging a handful of members from the 
> community to help with the transition.  Specifically, there are those who 
> really value using email for participation on swift-evolution and 
> swift-users, and the goal is to get the forum setup to allow those people to 
> continue to feel effective when using email for discussions on these "lists".
> 
> More details will be announced as they get figured out, but I felt it was 
> important to let the community know about this direction.
> 
> Ted
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-users] for with optional collection?

[David Hart via swift-users]

someOptionalCollection?.forEach { item in
}

> On 9 Feb 2017, at 22:48, Marco S Hyman via swift-users 
>  wrote:
> 
> 
>> On Feb 9, 2017, at 1:26 PM, Rick Mann via swift-users 
>>  wrote:
>> 
>> Is there any concise way to write the following?
>> 
>> if let collection = someOptionalCollection
>> {
>>   for item in collection
>>   {
>>   }
>> }
> 
> someOptionalCollection?.map {
>/* do something with $0 /*
> }
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Weird function call behaviour

[David Hart via swift-users]

In the following piece of code, can somebody explain the last result? Why the 
break in consistency? Is this a bug?

protocol P {
func foo() -> String
}

extension P {
func foo() -> String { return "P" }
}

class A : P {
func foo() -> String { return "A" }
}

class B : P {}
class C : B {
func foo() -> String { return "C" }
}

A().foo()  // A
(A() as P).foo()   // A
B().foo()  // P
(B() as P).foo()   // P
C().foo()  // C
(C() as P).foo()   // P___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Weird function call behaviour

[David Hart via swift-users]

> On 22 Feb 2017, at 21:59, Slava Pestov via swift-users 
>  wrote:
> 
> When a class conforms to a protocol and a requirement is fulfilled by a 
> method in an extension, the class does not get a vtable entry for the 
> extension method. So it cannot be overridden in a subclass — there’s nothing 
> to dynamically dispatch here. We plan on addressing this as part of ABI 
> stability.

What do you mean by “address” this? Force the vtable entry?

> Slava
> 
> 
>> On Feb 22, 2017, at 9:39 AM, David Hart via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> In the following piece of code, can somebody explain the last result? Why 
>> the break in consistency? Is this a bug?
>> 
>> protocol P {
>>  func foo() -> String
>> }
>> 
>> extension P {
>>  func foo() -> String { return "P" }
>> }
>> 
>> class A : P {
>>  func foo() -> String { return "A" }
>> }
>> 
>> class B : P {}
>> class C : B {
>>  func foo() -> String { return "C" }
>> }
>> 
>> A().foo()  // A
>> (A() as P).foo()   // A
>> B().foo()  // P
>> (B() as P).foo()   // P
>> C().foo()  // C
>> (C() as P).foo()   // P
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Weird function call behaviour

[David Hart via swift-users]

> On 22 Feb 2017, at 22:02, Slava Pestov via swift-users 
>  wrote:
> 
> 
>> On Feb 22, 2017, at 1:01 PM, David Hart > <mailto:david.w.h...@me.com>> wrote:
>> 
>> 
>>> On 22 Feb 2017, at 21:59, Slava Pestov via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> When a class conforms to a protocol and a requirement is fulfilled by a 
>>> method in an extension, the class does not get a vtable entry for the 
>>> extension method. So it cannot be overridden in a subclass — there’s 
>>> nothing to dynamically dispatch here. We plan on addressing this as part of 
>>> ABI stability.
>> 
>> What do you mean by “address” this? Force the vtable entry?
> 
> Yeah. Instead of having the witness table for the conformance point directly 
> to the extension method, if the conforming type is a class, we will generate 
> a small thunk that calls a vtable entry, and store the extension method in 
> that vtable entry.
> 
> Of course this will only work if the conformance is defined in the same 
> translation unit as the class; if you define the extension in a different 
> module, you’ll get the same behavior you observe below.

Sound great :)

> Slava
> 
>> 
>>> Slava
>>> 
>>> 
>>>> On Feb 22, 2017, at 9:39 AM, David Hart via swift-users 
>>>> mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> In the following piece of code, can somebody explain the last result? Why 
>>>> the break in consistency? Is this a bug?
>>>> 
>>>> protocol P {
>>>>func foo() -> String
>>>> }
>>>> 
>>>> extension P {
>>>>func foo() -> String { return "P" }
>>>> }
>>>> 
>>>> class A : P {
>>>>func foo() -> String { return "A" }
>>>> }
>>>> 
>>>> class B : P {}
>>>> class C : B {
>>>>func foo() -> String { return "C" }
>>>> }
>>>> 
>>>> A().foo()  // A
>>>> (A() as P).foo()   // A
>>>> B().foo()  // P
>>>> (B() as P).foo()   // P
>>>> C().foo()  // C
>>>> (C() as P).foo()   // P
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Improving compilation times?

[David Hart via swift-users]

Yes, it's best to avoid concatenating strings with +. Not only for performance 
reasons, but it's also less readable than string interpolation:

str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? "?")\n"

> On 23 Mar 2017, at 08:11, Rien via swift-users  wrote:
> 
> Thanks for that link, used it to track down the worst compile time offender:
> 
> This piece of code:
> 
> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
> -> String {
> 
>let addrInfoNil: UnsafeMutablePointer? = nil
>var count: Int = 0
>var info: UnsafeMutablePointer = infoPtr
>var str: String = ""
> 
>while info != addrInfoNil {
> 
>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
> (service ?? "?") + "\n"
>count += 1
>info = info.pointee.ai_next
>}
>return str
> }
> 
> Took 38 seconds to compile.
> 
> Removing the “str” assignment:
> 
> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
> -> String {
> 
>let addrInfoNil: UnsafeMutablePointer? = nil
>var count: Int = 0
>var info: UnsafeMutablePointer = infoPtr
>var str: String = ""
> 
>while info != addrInfoNil {
> 
>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
> + (service ?? "?") + "\n"
>count += 1
>info = info.pointee.ai_next
>}
>return str
> }
> 
> Brought it down to 6.6ms
> 
> Obviously I have to rewrite, but it does show how just one line of code can 
> be responsible for approx 80% of the compile time.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>>>  wrote:
>>> 
>>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>>> 
>>> Can somebody from the compiler or Xcode team share some tips on how to 
>>> improve compilation times of larger Swift projects?
>>> 
>>> I am an iOS developer and the largest issue my team has with Swift so far 
>>> is that when the project gets semi large (~30 000 lines) the compilation 
>>> times start to be high (~10 minutes from clean). This is a MAJOR downside 
>>> since iOS development oftentimes requires rapid changes to UI or logic. 
>>> Every person of my team compiles a project at least 10 times a day to test 
>>> new features or functionalities. When compilation times start to be higher 
>>> than 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>>> compiling. Not to mention the focus lost when this is happening.
>>> 
>>> I know the Swift Evolution list is buzzing with new ideas and features but 
>>> from my experience the compilation times is a CRITICAL thing to improve in 
>>> the next Swift release since it cost real money to waste all those 
>>> developer hours. Just think of all the hours lost on compiling across all 
>>> Swift devs worldwide and you will get to probably dozens of thousand of dev 
>>> hours a day.
>>> 
>>> Is the core compiler team going to address compilation performance in the 
>>> next release?
>>> 
>>> Maybe there is an existing solution to long compilation times that we don't 
>>> know of? It would be great if anybody could share.
>>> I was thinking maybe of dividing the app into multiple frameworks since I 
>>> think frameworks are compiled only once only on change?
>> 
>> Build time is always a goal. Pretty much every version of Swift has had 
>> changes intended to improve compilation time or decrease the frequency of 
>> recompilation.
>> 
>> Often a large part of the build time is spent in a handful of places where 
>> the compiler's type inference system behaves poorly. You can use the 
>> -debug-time-function-bodies and -debug-time-expression-type-checking flags 
>> to look for these places. You can often get huge decreases in compile time 
>> by adding an explicit type declaration in the right place in order to 
>> simplify the type inference engine's job.
>> 
>> Here's a walkthough of one such analysis:
>> Profiling your Swift compilation times
>> http://irace.me/swift-profiling
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] swift 4.0 "swift-version 4" errors with "type(of:"

[David Hart via swift-users]

That's worrisome. type is such a common identifier that I worry its going to 
break a lot of code, create some confusion and force the un-esthetic qualifying.

> On 19 May 2017, at 21:38, Slava Pestov via swift-users 
>  wrote:
> 
> Do you have a member named ‘type’ in the current scope?
> 
> We changed the behavior of type(of:) so that it behaves like a normal 
> declaration in the Swift module instead of a special keyword. Unfortunately 
> this means if you have a ‘type’ already visible in scope, you have to fully 
> qualify Swift.type(of:).
> 
> Slava
> 
>> On May 19, 2017, at 11:18 AM, Edward Connell via swift-users 
>>  wrote:
>> 
>> When running the compiler using the "-swift-version 4" flag, the compiler 
>> complains about creating a dynamic type. Errors are flagged from within 
>> concrete base classes and also within protocol extensions.
>> 
>> error: cannot invoke 'type' with an argument list of type '(of: Self)'
>> let newObject = type(of: self).init()
>> 
>> Has this changed?? Are we supposed to create dynamic types a different way 
>> now?
>> 
>> Thanks, Ed
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Runtime crash caused by (NS)CharacterSet.hasMember?

[David Hart via swift-users]

Worth a radar to improve docs.

> On 13 Jun 2017, at 22:12, Jens Persson via swift-users 
>  wrote:
> 
> Thanks!
> 
> The documentation that Xcode displays (for CharacterSet's hasMember(inPlane 
> plane:)) is as follows:
> 
> Declaration:
> func hasMember(inPlane plane: UInt8) -> Bool
> 
> Description:
> Returns true if the `CharacterSet` has a member in the specified plane.
> This method makes it easier to find the plane containing the members of the 
> current character set.
> The Basic Multilingual Plane (BMP) is plane 0.
> 
> Parameters:
> plane - No description
> 
> Which is about the same as here:
> https://developer.apple.com/documentation/foundation/characterset/1779728-hasmember
>  
> 
> and here:
> https://developer.apple.com/documentation/foundation/nscharacterset/1412406-hasmemberinplane
>  
> 
> 
> No where does it mention anything about undefined behavior for some values of 
> plane.
> 
> In order to find that crucial info, I'd have to do what you did, write it in 
> Objective C and dig through the stack trace, or just guess that it calls 
> CFCharacterSetHasMemberInPlane and that its documentation contains very 
> valuable pieces of information that for some reason got lost on the way to 
> NSCharacterSet's method hasMemberInPlane ...
> 
> Kind of makes one wonder what other undocumented undefined behavior might 
> hide in Foundation and other places.
> 
> /Jens
> 
> 
>  
> 
> On Tue, Jun 13, 2017 at 7:14 PM, Doug Hill via swift-users 
> mailto:swift-users@swift.org>> wrote:
> I tried your calls to NSFont in Objective-C, and it also crashes. Looking at 
> the stack trace, I see that it crashes in CFCharacterSetHasMemberInPlane. I 
> see documentation for thePlane parameter of this function says:
> 
> The valid value range is from 0 to 16.  If the value is outside of the valid 
> plane number range, the behavior is undefined.
> 
> I guess randomly crashing counts as undefined behavior.
> While it would be great if this function was more robust, Apple is definitely 
> saying Don’t Do That.
> 
> Doug Hill
> https://github.com/djfitz/SFFontFeatures 
> 
> 
> 
>> On Jun 13, 2017, at 9:42 AM, Jens Persson via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> PS
>> There are only 17 planes in the (current?) Unicode standard, but I'm 
>> assuming that the CharacterSet.hasMember(inPlane:) shouldn't (randomly?) 
>> crash for UInt8 values other than 0 ... 16?
>> It also seems strange that it reproducibly crashes or not depending on which 
>> specific font I use.
>> 
>> 
>> On Tue, Jun 13, 2017 at 4:00 PM, Jens Persson > > wrote:
>> The below program demonstrates a possible bug that I encountered.
>> Can anyone else reproduce my results (as explained in the comments)?
>> If so, is it a Swift or Cocoa bug (I haven't tried it in Objective C)?
>> 
>> import AppKit
>> 
>> extension NSFont {
>> var planesWithMembers: [UInt8] {
>> return (UInt8(0) ... UInt8(255)).filter {
>> // The follwing line will crash (EXC_BAD_ACCESS) for some fonts:
>> coveredCharacterSet.hasMember(inPlane: $0)
>> // I have tested it with Xcode 8.3.3 and Xcode 9 beta 1, both
>> // Swift 3 and 4, and they all reproduce the crash.
>> // macOS 10.12.5
>> }
>> }
>> }
>> 
>> // Examples that will not cause the crash:
>> // let fontName = "AlBayan"
>> // let fontName = "AppleBraille"
>> // let fontName = "Chalkboard"
>> // let fontName = "Helvetica"
>> // let fontName = "Zapfino"
>> 
>> // Examples that will cause the crash:
>> // let fontName = "AppleColorEmoji"
>> // let fontName = "AppleSymbols"
>> let fontName = "Baskerville"
>> // let fontName = "Geneva"
>> // let fontName = "SnellRoundhand"
>> 
>> let font = NSFont(name: fontName, size: 12)!
>> let result = font.planesWithMembers
>> print("Planes that contains members:", result)
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[David Hart via swift-users]

> On 23 Jun 2017, at 03:45, Jon Shier via swift-users  
> wrote:
> 
>   I’m sorry, are you complaining about my use of Codable instead of more 
> precisely referring to the JSON endcode/decode functionality based on it in 
> Foundation, or are you honestly trying to say that said functionality was 
> never intended to be a general purpose JSON solution? If it’s not actually 
> intended to handle all JSON you should probably call it something else.

Hi Jon,

First of all, I'd like to point out that I've found your tone to be quite rude. 
Calling the design of Codable, that has gotten a lot of work from Apple and 
swift-evolution, as silly is insulting and can leave people hurt. If you have 
found it lacking, please say so: we're all here to discuss any feedback people 
have had with Swift. But please do so with respect for the people and the work 
behind it.

Now, concerning Codable, I find its name quite apt. It was never intended to be 
used a full JSON parser but as a strongly-typed Swift equivalent of 
Objective-C's NSCoding, which is nothing more than a framework for serializing 
and deserializing types into different file formats.

David.

> Jon
> 
>>> On Jun 22, 2017, at 9:42 PM, Greg Parker  wrote:
>>> 
>>> 
>>> On Jun 22, 2017, at 6:00 PM, Jon Shier via swift-users 
>>>  wrote:
>>> 
>>> My main concern here is that, as Swift’s official JSON parsing method, 
>>> Codable should be able to handle any JSON representation and use and it 
>>> doesn’t.
>> 
>> Is this true? Is Codable intended to be Swift's official JSON parsing 
>> system? Is Codable intended to be a general-purpose JSON parsing system? 
>> 
>> My understanding was that Codable was designed to serialize Swift types, not 
>> to be able to import arbitrary JSON text into Swift nor to interoperate with 
>> every existing JSON API.
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] ⁨Is it possible to store a set of heterogeneous items with protocol?

[David Hart via swift-users]

> On 19 Jul 2017, at 09:22, Glen Huang via swift-users  
> wrote:
> 
> Thanks for the heads up.
> 
> I wonder what’s the root cause of the difficulty to make "such an existential 
> conform to Hashable in a general way”. Is it because objects of different 
> types have local definitions for hash value, thus making it impossible to 
> compare them directly?

No. It’s because Hashable conforms to Equatable, and Equatable has a Self 
requirement. In English, it means that Equatable requires both of its arguments 
to be of the same type, which can’t be guaranteed in the context of an array of 
heterogenous items.

> Go is able to handle heterogeneous items defined by a protocol:
> 
> https://play.golang.org/p/8xtrZyTW40 
> 
> I’m no expert in language design, wonder how they are able to implement it.
> 
>> On 19 Jul 2017, at 2:34 PM, Slava Pestov > > wrote:
>> 
>> Hopefully we will one day have generalized existentials which would at least 
>> allow a heterogeneous array of protocols with an associated type; however it 
>> is not clear how such an existential could conform to Hashable in a general 
>> way, given that Hashable implies Equatable which has a Self requirement.
>> 
>> Slava
>> 
>>> On Jul 18, 2017, at 10:36 PM, Glen Huang via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> Do you think if there will be any evolution proposal to address this 
>>> limitation? Or it’s an inherent tradeoff that is unlikely to be changed?
>>> 
 On 19 Jul 2017, at 8:49 AM, Jordan Rose >>> > wrote:
 
 
 
> On Jul 18, 2017, at 10:33, Vladimir.S via swift-users 
> mailto:swift-users@swift.org>> wrote:
> 
> On 17.07.2017 4:51, Glen Huang via swift-users wrote:
>> Thanks for the code sample and link, but if I’m not wrong, this pattern 
>> doesn’t allow heterogeneous items.
> 
> Support the question. Trying to understand if we can have something like 
> [AnyHashable] for our custom protocol(with associated type) or 
> AnyHashable has a very special support from compiler and we can use only 
> [Any] or such kind of wrapper:
> 
> struct AnyMyProtocol {
>  let actualInstance: Any
>  init(_ instance: T) { actualInstance = instance}
> }
> 
> let instances: [AnyMyProtocol] = [AnyMyProtocol(...), AnyMyProtocol(...)]
> 
> if let some = instances[0].actualInstance as? 
> SpecificImplementationOfMyProtocol {
>   // use 'some' as SpecificImplementationMyProtocol instance
>   // seems like no way to refer to just MyProtocol
> }
 
 AnyHashable is special, sorry. You'll have to use this sort of indirect 
 unwrapping instead. You can write a little convenience method for it 
 though, if you want:
 
 extension AnyMyProtocol {
   func get(as: T.Type) -> T? {
 return self.actualInstance as? T
   }
 }
 
 if let some = instances[0].get(as: 
 SpecificImplementationOfMyProtocol.self) {
   // use 'some' here
 }
 
 Jordan
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] ⁨Is it possible to store a set of heterogeneous items with protocol?

[David Hart via swift-users]

> On 19 Jul 2017, at 09:22, Glen Huang via swift-users  
> wrote:
> 
> Thanks for the heads up.
> 
> I wonder what’s the root cause of the difficulty to make "such an existential 
> conform to Hashable in a general way”. Is it because objects of different 
> types have local definitions for hash value, thus making it impossible to 
> compare them directly?

No. It’s because Hashable conforms to Equatable, and Equatable has a Self 
requirement. In English, it means that Equatable requires both of its arguments 
to be of the same type, which can’t be guaranteed in the context of an array of 
heterogenous items.

> 
> Go is able to handle heterogeneous items defined by a protocol:
> 
> https://play.golang.org/p/8xtrZyTW40 
> 
> I’m no expert in language design, wonder how they are able to implement it.
> 
>> On 19 Jul 2017, at 2:34 PM, Slava Pestov > > wrote:
>> 
>> Hopefully we will one day have generalized existentials which would at least 
>> allow a heterogeneous array of protocols with an associated type; however it 
>> is not clear how such an existential could conform to Hashable in a general 
>> way, given that Hashable implies Equatable which has a Self requirement.
>> 
>> Slava
>> 
>>> On Jul 18, 2017, at 10:36 PM, Glen Huang via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> Do you think if there will be any evolution proposal to address this 
>>> limitation? Or it’s an inherent tradeoff that is unlikely to be changed?
>>> 
 On 19 Jul 2017, at 8:49 AM, Jordan Rose >>> > wrote:
 
 
 
> On Jul 18, 2017, at 10:33, Vladimir.S via swift-users 
> mailto:swift-users@swift.org>> wrote:
> 
> On 17.07.2017 4:51, Glen Huang via swift-users wrote:
>> Thanks for the code sample and link, but if I’m not wrong, this pattern 
>> doesn’t allow heterogeneous items.
> 
> Support the question. Trying to understand if we can have something like 
> [AnyHashable] for our custom protocol(with associated type) or 
> AnyHashable has a very special support from compiler and we can use only 
> [Any] or such kind of wrapper:
> 
> struct AnyMyProtocol {
>  let actualInstance: Any
>  init(_ instance: T) { actualInstance = instance}
> }
> 
> let instances: [AnyMyProtocol] = [AnyMyProtocol(...), AnyMyProtocol(...)]
> 
> if let some = instances[0].actualInstance as? 
> SpecificImplementationOfMyProtocol {
>   // use 'some' as SpecificImplementationMyProtocol instance
>   // seems like no way to refer to just MyProtocol
> }
 
 AnyHashable is special, sorry. You'll have to use this sort of indirect 
 unwrapping instead. You can write a little convenience method for it 
 though, if you want:
 
 extension AnyMyProtocol {
   func get(as: T.Type) -> T? {
 return self.actualInstance as? T
   }
 }
 
 if let some = instances[0].get(as: 
 SpecificImplementationOfMyProtocol.self) {
   // use 'some' here
 }
 
 Jordan
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Law of Exclusivity runtime false positive?

[David Hart via swift-users]

Hello,

In Xcode 9 beta 4, Swift 4, I’m getting runtime errors popping up for 
Simultaneous accesses and I think they may be false negatives. Here’s a 
stripped down version of my code:

class MyButton: UIButton {
fileprivate var imageRect: CGRect = .zero
fileprivate var titleRect: CGRect = .zero

func updateRects() {
if imageBeforeTitle {
layoutHorizontally(leftRect: &imageRect, rightRect: &titleRect)
} else {
layoutHorizontally(leftRect: &titleRect, rightRect: &imageRect)
}
}

func layoutHorizontally(leftRect: inout CGRect, rightRect: inout 
CGRect) {
leftRect.origin.x = padding
rightRect.origin.x = leftRect.maxX + spacing
}
}

While the layoutHorizontally method has two CGRect inout parameters, never in 
my code do I pass the same CGRect. Any ideas if this is a bug I should post on 
bugs.swift.org or if I’m missing something?

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

Re: [swift-users] Law of Exclusivity runtime false positive?

[David Hart via swift-users]

Hello,

Indeed, I had reduced the code too much. John McCall was kind enough to have a 
look and here’s the offending code:

func layoutHorizontally(leftRect: inout CGRect, rightRect: inout CGRect) {
let totalWidth = imageRect.size.width + titleRect.size.width + 
contentSpacing
rightRect.origin.x = leftRect.maxX + contentSpacing
}

The problem is that imageRect and titleRect are referenced both directly and in 
the inout parameters.

But there’s something I’m not understanding. I went back to the ownership 
manifesto and re-read the law of exclusivity to make sure I understand it:

If a storage reference expression evaluates to a storage reference that is 
implemented by a variable, then the formal access duration of that access may 
not overlap the formal access duration of any other access to the same variable 
unless both accesses are reads.

So I tried to write a test to trigger the runtime error, but was unsuccessful:

class MyClass {
var p: CGRect = .zero
}

func trigger(a: MyClass, b: MyClass) {
a.p = b.p
}

let m = MyClass()
trigger(a: m, b: m)

Here, a storage reference expression (a.p) evaluates to a storage reference 
that is implemented by a variable (the p property of an instance m of MyClass) 
and its formal access duration (the trigger function) overlaps the formal 
access duration of another access to the same variable (through the b.p storage 
reference expression) and both accesses are not reads (a.p is on the LHS of an 
assignment).

Why does this not trigger the Law of Exclusivity?

Regards,
David.

> On 27 Jul 2017, at 21:33, Kyle Murray  wrote:
> 
> Hi David,
> 
> Are padding or spacing computed properties that access either rectangle? They 
> aren't defined in your stripped down code. For example:
> 
> var spacing: CGFloat {
> return imageRect.maxX
> }
> 
> Without doing something like that, I don't see the same access conflicts that 
> you're seeing.
> 
> -Kyle
> 
>> On Jul 27, 2017, at 5:04 AM, David Hart via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Hello,
>> 
>> In Xcode 9 beta 4, Swift 4, I’m getting runtime errors popping up for 
>> Simultaneous accesses and I think they may be false negatives. Here’s a 
>> stripped down version of my code:
>> 
>> class MyButton: UIButton {
>>  fileprivate var imageRect: CGRect = .zero
>>  fileprivate var titleRect: CGRect = .zero
>> 
>> func updateRects() {
>> if imageBeforeTitle {
>> layoutHorizontally(leftRect: &imageRect, rightRect: 
>> &titleRect)
>> } else {
>> layoutHorizontally(leftRect: &titleRect, rightRect: 
>> &imageRect)
>> }
>> }
>> 
>> func layoutHorizontally(leftRect: inout CGRect, rightRect: inout 
>> CGRect) {
>> leftRect.origin.x = padding
>> rightRect.origin.x = leftRect.maxX + spacing
>> }
>> }
>> 
>> While the layoutHorizontally method has two CGRect inout parameters, never 
>> in my code do I pass the same CGRect. Any ideas if this is a bug I should 
>> post on bugs.swift.org <http://bugs.swift.org/> or if I’m missing something?
>> 
>> David.
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

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

Re: [swift-users] Law of Exclusivity runtime false positive?

[David Hart via swift-users]

> On 28 Jul 2017, at 18:55, Joe Groff  wrote:
> 
>> 
>> On Jul 28, 2017, at 12:06 AM, David Hart via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Hello,
>> 
>> Indeed, I had reduced the code too much. John McCall was kind enough to have 
>> a look and here’s the offending code:
>> 
>> func layoutHorizontally(leftRect: inout CGRect, rightRect: inout CGRect) {
>> let totalWidth = imageRect.size.width + titleRect.size.width + 
>> contentSpacing
>> rightRect.origin.x = leftRect.maxX + contentSpacing
>> }
>> 
>> The problem is that imageRect and titleRect are referenced both directly and 
>> in the inout parameters.
>> 
>> But there’s something I’m not understanding. I went back to the ownership 
>> manifesto and re-read the law of exclusivity to make sure I understand it:
>> 
>> If a storage reference expression evaluates to a storage reference that is 
>> implemented by a variable, then the formal access duration of that access 
>> may not overlap the formal access duration of any other access to the same 
>> variable unless both accesses are reads.
>> 
>> So I tried to write a test to trigger the runtime error, but was 
>> unsuccessful:
>> 
>> class MyClass {
>> var p: CGRect = .zero
>> }
>> 
>> func trigger(a: MyClass, b: MyClass) {
>> a.p = b.p
>> }
>> 
>> let m = MyClass()
>> trigger(a: m, b: m)
>> 
>> Here, a storage reference expression (a.p) evaluates to a storage reference 
>> that is implemented by a variable (the p property of an instance m of 
>> MyClass) and its formal access duration (the trigger function) overlaps the 
>> formal access duration of another access to the same variable (through the 
>> b.p storage reference expression) and both accesses are not reads (a.p is on 
>> the LHS of an assignment).
>> 
>> Why does this not trigger the Law of Exclusivity?
> 
> `b.p` is loaded before `a.p` is written to, so the accesses do not overlap 
> even when a === b. Something like swap(&a.p, &b.p) (using the Swift 3 global 
> definition of 'swap') would trigger an exclusivity trap when a === b, since 
> the access to storage passed as an inout argument needs to last for the 
> duration of the call.

Thanks for the explanation! It’s starting to make sense :) Is it possible to 
trigger the exclusivity trap without an inout argument?

> -Joe

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

[swift-users] Broken Syntax Highlighting + Code Completion

[David Hart via swift-users]

Hi everybody,

I have a 99% pure Swift 4 project (1% of Objective-C) in Xcode 9 beta 6 and the 
syntax highlighting and code completion is completely broken. I’m writing here 
in case it’s a Swift problem and unrelated to Xcode.

Jordan Rose suggested I run Xcode with SOURCEKIT_LOGGING=2 and here are the 
outputted logs:

default 18:22:07.321659 +0200   com.apple.dt.SKAgent IDEIndexing: 
SwiftDataSource: No import session for file ‘File1.swift’
default 18:22:07.321659 +0200   com.apple.dt.SKAgent IDEIndexing: 
SwiftDataSource: No import session for file ‘File2.swift'
// ... one for each file in the project
default 18:22:07.791113 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.792943 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.794858 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.796640 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.798514 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.800277 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.802086 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond
default 18:22:07.803843 +0200   com.apple.dt.SKAgent IDEIndexing: Failed to 
get settings for 
/Users/david/Projects/mimosa.iosapp/Vendor/CleanroomLogger/CleanroomLoggerTests-3B90590B1DAECB5200B4EEC0
 - build system did not respond

Any ideas if its a SourceKit or Xcode related issue?

Regards,
David.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Type of expression is ambiguous for static tuples

[David Hart via swift-users]

Its slightly different though. In the case of:

let cgColor: CGColor = .clear.cgColor

clear is a static property on UIColor, not CGColor. In his example, 
pythagoreanTriple is a property on Double so it does feel like a bug.

> On 1 Sep 2017, at 13:31, Adrian Zubarev via swift-users 
>  wrote:
> 
> It’s because the compiler does not support this yet. It’s the same with `let 
> cgColor: CGColor = .clear.cgColor // will not work`.
> 
> Instead you need to write `UIColor.clear.cgColor` or in your case 
> `Double.phythagoreanTruple.0`
> 
> 
> Am 1. September 2017 um 12:17:57, Rudolf Adamkovič via swift-users 
> (swift-users@swift.org ) schrieb:
> 
>> Given the following extension ...
>> 
>> extension Double {
>> typealias Triple = (Double, Double, Double)
>> static let pythagoreanTriple: Triple = (3, 4, 5)
>> }
>> ... why does Swift compiler emits the following errors?
>> 
>> // Type of expression is ambiguous without more context
>> let a: Double = .pythagoreanTriple.0
>> 
>> // Type of expression is ambiguous without more context
>> func f(_ x: Double) {}
>> f(.pythagoreanTriple.0)
>> The errors disappear with explicit Double.pythagoreanTriple.0.
>> 
>> Why doesn't the compiler infer Double in this case?
>> 
>> FYI: Posted also to Stack Overflow here:
>> 
>> https://stackoverflow.com/questions/45998034/type-of-expression-is-ambiguous-for-static-tuples
>>  
>> 
>> R+
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

[David Hart via swift-users]

Hello!

Thanks for noticing a bug and taking the time to fix it :) Here are the steps 
for contributing:

Fork the project (you’ve already done that).
Clone the fork to your computer.
Branch off master and name the branch after the fix (I like to name them with 
the sr number).
Write the fix and the test that validates it (i 
f
 you’re looking for help here, you can read this documentation from the 
corelibs foundation repo: 
https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/GettingStarted.md)
Push your branch to the remote.
On GitHub, open a Pull Request and wait for somebody to look into it.

If anybody notices that I’ve forgotten a step, please let me know. Meanwhile, 
if you need any help Benoit, I’m available to chat (in French or English) on 
the SwiftPM Slack at https://swift-package-manager.herokuapp.com 


Regards,
David Hart.

> On 18 Dec 2017, at 11:34, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001} »
>   // should be : "{"seconds":1.1001} »
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l’expéditeur.
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] [swift-evolution] Happy new year Swift community.

[David Hart via swift-users]

Thank you very much and happy new Swift year to everybody.

> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Well some of you guys have to wait a little longer, but I can already wish 
> everyone a happy new year from Germany. 🎉🎊🎆🎇 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Parameter Validation

[David Hart via swift-users]

I’m looking at the special case of library code. If I surface an API in a 
library, it’s the library user who will call this function. Would you regard 
this as an assert or throws scenario?

> On 07 Dec 2015, at 08:25, Brent Royal-Gordon via swift-users 
>  wrote:
> 
>> When writing library code, what method of parameter validation would be 
>> suggested?
> 
> It depends.
> 
> If the data may come from somewhere out of your control, like a user or the 
> network, throws (or an optional or Bool return value) is an appropriate 
> choice.
> 
> If the data will come from a source which should “never” be wrong, like data 
> that has already been parsed or a calculation you perform, then 
> precondition() (rather than assert(), which is removed in production builds) 
> is a good way to run a sanity check.
> 
> Basically, if you anticipate that the value could ever be invalid, use throws 
> or an optional/boolean return. If you don’t think the value should ever be 
> invalid, use precondition().
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

[David Hart via swift-users]

How is it that Swift allows code like this:

struct Sneaky: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}
}

func ~=(sneaky: Sneaky, string: String) -> Bool {
return false
}

enum NormalEnum: String {
case Super = "super"
case Mario = "mario"
}

let value = NormalEnum(rawValue: "super”) // return nil

It hit completely by surprise today because of of a Regex library:

struct Regex: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}

//...
}

func ~=(regex: Regex, string: String) -> Bool {
return regex.matches(string)
}

If I was not already a Swift enthusiast, this behaviour would have left me 
completely dumbfounded.
What can we do about it?

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

[swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

[David Hart via swift-users]

How is it that Swift allows code like this:

struct Sneaky: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}
}

func ~=(sneaky: Sneaky, string: String) -> Bool {
return false
}

enum NormalEnum: String {
case Super = "super"
case Mario = "mario"
}

let value = NormalEnum(rawValue: "super”) // return nil

It hit completely by surprise today because of of a Regex library:

struct Regex: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}

//...
}

func ~=(regex: Regex, string: String) -> Bool {
return regex.matches(string)
}

If I was not already a Swift enthusiast, this behaviour would have left me 
completely dumbfounded.
What can we do about it?

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

Re: [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

[David Hart via swift-users]

Sorry about the double post.

> On 05 Jan 2016, at 18:26, David Hart via swift-users  
> wrote:
> 
> How is it that Swift allows code like this:
> 
> struct Sneaky: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> }
> 
> func ~=(sneaky: Sneaky, string: String) -> Bool {
>   return false
> }
> 
> enum NormalEnum: String {
>   case Super = "super"
>   case Mario = "mario"
> }
> 
> let value = NormalEnum(rawValue: "super”) // return nil
> 
> It hit completely by surprise today because of of a Regex library:
> 
> struct Regex: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> 
>   //...
> }
> 
> func ~=(regex: Regex, string: String) -> Bool {
>   return regex.matches(string)
> }
> 
> If I was not already a Swift enthusiast, this behaviour would have left me 
> completely dumbfounded.
> What can we do about it?
> 
> David.
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

[David Hart via swift-users]

To bring a little bit more context: I copied this Regex library in my project 
which had StringLiteralConvertible and implemented the pattern matching 
operator and all of a sudden, ALL init(rawValue: String) calls of completely 
unrelated enums started returning unexpected values. If I did not have unit 
tests, I probably would not have found out about it for a while.

I understand the mechanism which calls StringLiteralConvertible's 
init(stringLiteral) under the hood:

let a: SomeStringLiteralConvertibleType = "hello"

I also understand the magic in the pattern matching operator. But I don't 
understand why when associating them together:

func ~=(lhs: SomeStringLiteralConvertibleType, rhs: String) -> Bool {
return false
}

Then creates his behaviour in all Enums with String raw values:

enum MyEnum: String {
case Super = "super"
}

let a = MyEnum(rawValue: "super") // nil

I can't figure out if this is just a confusing behaviour of Swift, in which 
case I want to write a proposal to make it less confusing, or if it is a big 
with Swift, in which case I should open a bug report.

David

> On 05 Jan 2016, at 18:26, David Hart via swift-users  
> wrote:
> 
> How is it that Swift allows code like this:
> 
> struct Sneaky: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> }
> 
> func ~=(sneaky: Sneaky, string: String) -> Bool {
>   return false
> }
> 
> enum NormalEnum: String {
>   case Super = "super"
>   case Mario = "mario"
> }
> 
> let value = NormalEnum(rawValue: "super”) // return nil
> 
> It hit completely by surprise today because of of a Regex library:
> 
> struct Regex: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> 
>   //...
> }
> 
> func ~=(regex: Regex, string: String) -> Bool {
>   return regex.matches(string)
> }
> 
> If I was not already a Swift enthusiast, this behaviour would have left me 
> completely dumbfounded.
> What can we do about it?
> 
> David.
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-evolution] Very strange automatic behavior between StringLiteralConvertible and pattern matching

[David Hart via swift-users]

I'm starting to understand. The implementation of RawRepresentable's probably 
looks like this:

init?(rawValue: String) {
switch rawValue {
case "firstValue": self = .FirstCase
case "secondValue": self = .SecondCase
default: return nil
}
}

In that case (no pun intended), the switch cases are converted to 
SomeStringLiteralConvertibleType and then pattern matched.

But shouldn't the implementation of switch refrain from any complicated casting 
when the types correspond?

David.

> On 06 Jan 2016, at 10:20, David Hart via swift-evolution 
>  wrote:
> 
> To bring a little bit more context: I copied this Regex library in my project 
> which had StringLiteralConvertible and implemented the pattern matching 
> operator and all of a sudden, ALL init(rawValue: String) calls of completely 
> unrelated enums started returning unexpected values. If I did not have unit 
> tests, I probably would not have found out about it for a while.
> 
> I understand the mechanism which calls StringLiteralConvertible's 
> init(stringLiteral) under the hood:
> 
> let a: SomeStringLiteralConvertibleType = "hello"
> 
> I also understand the magic in the pattern matching operator. But I don't 
> understand why when associating them together:
> 
> func ~=(lhs: SomeStringLiteralConvertibleType, rhs: String) -> Bool {
> return false
> }
> 
> Then creates his behaviour in all Enums with String raw values:
> 
> enum MyEnum: String {
> case Super = "super"
> }
> 
> let a = MyEnum(rawValue: "super") // nil
> 
> I can't figure out if this is just a confusing behaviour of Swift, in which 
> case I want to write a proposal to make it less confusing, or if it is a big 
> with Swift, in which case I should open a bug report.
> 
> David
> 
>> On 05 Jan 2016, at 18:26, David Hart via swift-users  
>> wrote:
>> 
>> How is it that Swift allows code like this:
>> 
>> struct Sneaky: StringLiteralConvertible {
>>  init(stringLiteral value: String) {}
>>  init(extendedGraphemeClusterLiteral value: String) {}
>>  init(unicodeScalarLiteral value: String) {}
>> }
>> 
>> func ~=(sneaky: Sneaky, string: String) -> Bool {
>>  return false
>> }
>> 
>> enum NormalEnum: String {
>>  case Super = "super"
>>  case Mario = "mario"
>> }
>> 
>> let value = NormalEnum(rawValue: "super”) // return nil
>> 
>> It hit completely by surprise today because of of a Regex library:
>> 
>> struct Regex: StringLiteralConvertible {
>>  init(stringLiteral value: String) {}
>>  init(extendedGraphemeClusterLiteral value: String) {}
>>  init(unicodeScalarLiteral value: String) {}
>> 
>>  //...
>> }
>> 
>> func ~=(regex: Regex, string: String) -> Bool {
>>  return regex.matches(string)
>> }
>> 
>> If I was not already a Swift enthusiast, this behaviour would have left me 
>> completely dumbfounded.
>> What can we do about it?
>> 
>> David.
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

[David Hart via swift-users]

I can file those bugs. Would it be beneficial if I also created failing unit 
tests?
David.

> On 06 Jan 2016, at 20:05, Joe Groff  wrote:
> 
>> 
>> On Jan 5, 2016, at 9:28 AM, David Hart via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> How is it that Swift allows code like this:
>> 
>> struct Sneaky: StringLiteralConvertible {
>>  init(stringLiteral value: String) {}
>>  init(extendedGraphemeClusterLiteral value: String) {}
>>  init(unicodeScalarLiteral value: String) {}
>> }
>> 
>> func ~=(sneaky: Sneaky, string: String) -> Bool {
>>  return false
>> }
>> 
>> enum NormalEnum: String {
>>  case Super = "super"
>>  case Mario = "mario"
>> }
>> 
>> let value = NormalEnum(rawValue: "super”) // return nil
> 
> I see two bugs here. When an enum has a raw value type, the compiler 
> generates this initializer:
> 
> init(rawValue: String) {
>   switch rawValue {
>   case "super":
> self = .Super
>   ...
>   }
> }
> 
> so uses ~= pattern matching to match the raw value. It would be more sensible 
> to always use `==` comparison in the synthesized initializer. However, I'm 
> surprised too that the type checker favors ~=(Sneaky, String) over ~=(String, 
> String); it should at best be ambiguous. Do you have time to file these two 
> bugs?
> 
> -Joe
> 
>> 
>> It hit completely by surprise today because of of a Regex library:
>> 
>> struct Regex: StringLiteralConvertible {
>>  init(stringLiteral value: String) {}
>>  init(extendedGraphemeClusterLiteral value: String) {}
>>  init(unicodeScalarLiteral value: String) {}
>> 
>>  //...
>> }
>> 
>> func ~=(regex: Regex, string: String) -> Bool {
>>  return regex.matches(string)
>> }
>> 
>> If I was not already a Swift enthusiast, this behaviour would have left me 
>> completely dumbfounded.
>> What can we do about it?
>> 
>> David.
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <https://lists.swift.org/mailman/listinfo/swift-users>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Checking/getting custom objects from a collection

[David Hart via swift-users]

Unity, the game engine, uses a component system heavily. It uses C# and 
retrieves components using generic functions. And no, it doesn't force having a 
single instance of each component class:

http://swiftlang.ng.bluemix.net/#/repl/7be36f2d70a31da3b6ab09b7b89277a4463c23b40c28e1663e56c959a1f3eca8

Crashes the compiler, but that's how I would implement it.

Sent from my iPad
> On 08 Apr 2016, at 02:29, Jens Alfke via swift-users  
> wrote:
> 
> I’m not familiar with this design pattern, but it looks like Entity would 
> just contain an array of Component. That makes add() and remove() 
> straightforward.
> 
> I’m not sure about your get() method. It sounds as though the implication is 
> that an entity could only contain a single component of a given class, but 
> that sounds awfully limiting. (If Limb is a Component, then a Spider entity 
> needs eight of them…) I also don’t believe that Swift is dynamic enough to be 
> able to interrogate the classes of components that way at runtime. You could 
> implement that at a higher level by adding a `type` property to 
> ComponentType, that returns some component-type enumeration or maybe a 
> string, and checking component types via that property.
> 
> —Jens
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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