[swift-corelibs-dev] NSURL.fileSystemRepresentation implementation

[Eugene Gubin via swift-corelibs-dev]

As far as I understand NSURL is responsible for deallocating memory to
which UnsafePointer returned from NSURL.fileSystemRepresentation points to.
Could one use private buffer to store result
for NSURL.fileSystemRepresentation or layout of this class should be the
same as CFURL?
Also NSFileManager has similar method fileSystemRepresentationWithPath, but
I'm not sure about it  because it allocates memory that is not freed in
case of success.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] LazySequenceType: make prefix return a lazy collection

[Mark Aron Szulyovszky via swift-corelibs-dev]

Hi,

I came across hit issue while chaining filter() and prefix() on lazy
sequences:
https://bugs.swift.org/browse/SR-461

And started wondering if it would be more consistent if
lazy.filter().prefix() returned a custom
LazySequenceType instead of
Slice>>.

That way lazy.filter().prefix() could be used to chain *pure lazy
operations*, which can be actually quite useful in some cases.

I understand that this has implications, and it would make prefix() less
consistent in terms of return type, but it would eliminate confusion like
SR-461 .
Also, this wouldn't be a much different than how how lazy.filter() is
implemented, since it also returns a custom LazySequenceType instead of
SequenceType.

Has this been considered before? Would there be any cases where this would
create unintended side effects?
As far as I see, it wouldn't change the meaning of prefix(), only would it
extend its usefulness.

I submitted a PR to the SwiftSequence library that demonstrates the
implementation of this:
https://github.com/itchingpixels/SwiftSequence/commit/26101e5aec6c266048bbad4db7b44b9c453f07ca

And I'm happy to contribute to contribute it to stdlib if people find it
useful.

Thanks a lot!

Mark
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] corelibs-xctest + swiftpm

[Daniel Dunbar via swift-corelibs-dev]

I think this makes sense (and commented in your PR). For now we will still need 
the manual build process because we need XCTest to build first in CI, so that 
we can use it in building/testing the package manager itself, but it certainly 
makes sense to shoot for it to just be yet another package.

 - Daniel

> On Dec 31, 2015, at 11:42 AM, Keith Smiley via swift-corelibs-dev 
>  wrote:
> 
> Hey all,
> 
> I was working on integrating a project with corelibs-xctest and I noticed that
> it doesn't currently support building with swiftpm and instead provides
> `.xcodeproj` which generates a `.framework`. Is there any future plan to also
> include a `Package.swift` so that user's could build it either way? Because of
> how simple corelibs-xctest is this is just a matter of including a barebones
> `Package.swift` and moving the source files.
> 
> 
> Thanks!
> 
> --
> Keith Smiley
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] NSArray.descriptionWithLocale implementation

[Tony Parker via swift-corelibs-dev]

Hi Eugene,

Interesting question. I think we may have to introduce a default implementation 
of -descriptionWithLocale:indent: which calls -descriptionWithLocale:, which 
has a default implementation of calling -description. 

It may be the case that we then have to limit the behavior to subclasses of 
NSObject.

- Tony

> On Dec 21, 2015, at 8:57 AM, Eugene Gubin via swift-corelibs-dev 
>  wrote:
> 
> Documentation says what it checks for item to respond to specific selectors. 
> There are no selectors in Swift, so new implementation should check for 
> protocol conformance instead, I guess. Any ideas? Should new protocol be 
> introduced?
> 
> Class reference:  
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/#//apple_ref/occ/instm/NSArray/descriptionWithLocale:indent
>  
> :
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Inconsistencies between Foundation APIs

[Tony Parker via swift-corelibs-dev]

Hi Ian,

Any place where the API differs should be marked with a comment like this:

/// - Experiment: This is a draft API currently under consideration for 
official import into Foundation

If not, then we found some place that we either need to change or propose a 
change for. We can track those with bugs on bugs.swift.org 
. Most of the ‘Experiment’ APIs are something we have 
no alternative but to change, though.

Thanks for your work on this,
- Tony

> On Dec 21, 2015, at 5:39 PM, Ian Ynda-Hummel via swift-corelibs-dev 
>  wrote:
> 
> I've been working on SR-276  and I'm 
> finding a fair amount of inconsistencies between corelib Foundation and OS X 
> Foundation. It seems to be most common with optionality of return values. 
> e.g., in NSURL
> 
> corelib:
> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL?
> 
> OS X:
> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL
> 
> That particular case seems to be a difference in the treatment of the return 
> value from CFURL
> 
>public func CFURLCreateCopyAppendingPathComponent(allocator: CFAllocator!, 
> _ url: CFURL!, _ pathComponent: CFString!, _ isDirectory: Bool) -> CFURL!
> 
> Which briefly looking appears to be the same between corelib and OS X.
> 
> I'm not sure what the best way forward on these things is, though, as the 
> corelib versions have seemed consistently improved, but presumably we still 
> want maintain compatibility. Anyone have ideas?
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Inconsistencies between Foundation APIs

[Ian Ynda-Hummel via swift-corelibs-dev]

Got it. I've seen the experimental thing elsewhere in the code. I'll work
under the assumption that inconsistencies are experimental and I'll open
bugs for things that are inconsistent but not marked as such.

On Mon, Jan 4, 2016 at 2:51 PM Tony Parker  wrote:

> Hi Ian,
>
> Any place where the API differs should be marked with a comment like this:
>
> /// - Experiment: This is a draft API currently under consideration for
> official import into Foundation
>
> If not, then we found some place that we either need to change or propose
> a change for. We can track those with bugs on bugs.swift.org. Most of the
> ‘Experiment’ APIs are something we have no alternative but to change,
> though.
>
> Thanks for your work on this,
> - Tony
>
> On Dec 21, 2015, at 5:39 PM, Ian Ynda-Hummel via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> I've been working on SR-276  and
> I'm finding a fair amount of inconsistencies between corelib Foundation and
> OS X Foundation. It seems to be most common with optionality of return
> values. e.g., in NSURL
>
> corelib:
> public func URLByAppendingPathComponent(pathComponent: String) ->
> NSURL?
>
> OS X:
> public func URLByAppendingPathComponent(pathComponent: String) ->
> NSURL
>
> That particular case seems to be a difference in the treatment of the
> return value from CFURL
>
>public func CFURLCreateCopyAppendingPathComponent(allocator:
> CFAllocator!, _ url: CFURL!, _ pathComponent: CFString!, _ isDirectory:
> Bool) -> CFURL!
>
> Which briefly looking appears to be the same between corelib and OS X.
>
> I'm not sure what the best way forward on these things is, though, as the
> corelib versions have seemed consistently improved, but presumably we still
> want maintain compatibility. Anyone have ideas?
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

Ok, after trying to get this building on Linux, I have discovered what you 
mean. I have gotten it building successfully on Linux, unfortunately this 
required changes to build settings in other modules, because 
/usr/include/libxml2 wasn’t being added to the search locations. And this then 
results in needing to add “-I/usr/include/libxml2” to the command line any time 
you want to build anything using Foundation! (including just typing “import 
Foundation” in the REPL, heh). Which is obviously less than ideal. There is 
already an implementation for all this stuff in CoreFoundation, but it’s marked 
as being deprecated as of OS X 10.6, with a note to use NSXMLDocument (or 
libxml2) instead! Not exactly a helpful recommendation when you’re implementing 
NSXMLDocument heh. Should I just add wrappers in CFXMLInterface for the libxml2 
functions I need? That might be the easiest way to just get everything building 
with minimal changes to other modules.

Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com 
 

> On Dec 18, 2015, at 8:05 PM, Philippe Hausler  wrote:
> 
> Dealing with the cross platform part of the module map portion may be a bit 
> tricky; I had to use some of libxml2 for CFXMLInterface it is effectively a 
> simple wrapper around a few xml c calls that are a bit swift-friendlier. 
> Perhaps that might make some of that integration easier. However if you do 
> find a decent way of dealing with the module map differentials between linux 
> and mac os x I would be interested to see if we could improve the state of 
> affairs in that bridged portion.
> 
>> On Dec 18, 2015, at 2:33 PM, Robert Stephen Thompson via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Ok, sounds good to me. I have quite a bit done at this point, but it’s not 
>> “pretty enough” for a real PR yet. If people really want to look at the 
>> ugliness, 
>> https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument
>>  
>> 
>>  is where it lives.
>> 
>> Thanks,
>> Robert
>>> On Dec 18, 2015, at 1:58 PM, Tony Parker >> > wrote:
>>> 
>>> Hi Robert,
>>> 
>>> There actually already is some discussion on the swift-evolution list about 
>>> a language feature to enable factory methods, which would help us to 
>>> implement these kinds of things. It is a common pattern in Foundation to 
>>> return subclasses from initializers (NSNull, NSPredicate are in the same 
>>> boat, among many others), so I’m hoping we can get that one moving along 
>>> soon. If you can find that thread, go ahead and reply to it with additional 
>>> justification if you want.
>>> 
>>> I think we should try to move forward on this as if we’ll eventually get 
>>> that feature. It’s pretty clear that we need it. We may need to work on 
>>> other parts of the implementation first until we get it.
>>> 
>>> - Tony
>>> 
 On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via 
 swift-corelibs-dev >>> > wrote:
 
 Since I recently did a small implementation of NSXMLNode and NSXMLDocument 
 to use in an iOS project, I decided to tackle doing the full-featured one 
 here. It’s not that hard, doing it as a wrapper on libxml2, except I’ve 
 run into a bit of a snag with making the semantics exactly match Darwin 
 Foundation: you can’t return a subclass from init! This really only 
 matters in one place, but it matters quite a bit there. The de facto 
 designated initializer for NSXMLNode is init(kind: NSXMLNodeKind, options: 
 Int). In pure Swift, this always returns an NSXMLNode, not the appropriate 
 subclass! Which, of course, means as? returns nil, as! (and 
 unsafeDowncast) crash, etc, when you end up trying to retrieve one and 
 treat it as the subclass it’s “supposed” to be. I’m completely stumped as 
 to any way around this. It might be that it’s just impossible to match 
 Darwin Foundation semantics without a new language feature for this, which 
 obviously would have to go through swift-evolution and then actually be 
 implemented. Am I correct, or is there something I’m missing? Also, should 
 I go ahead and implement the rest of this without the exactly matching 
 semantics because something is better than nothing?
 
 Thanks,
 Robert Thompson
 Software Engineer
 WillowTree, Inc.®
 willowtreeapps.com 
  
 
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
 
>>> 
>> 
>>  ___
>> swift-corelibs-d

Re: [swift-corelibs-dev] [xctest] Terminology: What to call "swift-corelibs-xctest" and "Apple XCTest"

[Tony Parker via swift-corelibs-dev]

We’ve also used “Darwin Foundation” vs “Swift Core Libraries Foundation.”

I’m open to suggestions on this from everyone. I haven’t found a set of terms 
that I’m really happy with yet.

- Tony

> On Dec 24, 2015, at 9:26 AM, Daniel Dunbar via swift-corelibs-dev 
>  wrote:
> 
> I believe we have been saying "Corelibs XCTest", but agree it would be nice 
> to have a standard labelling.
> 
> - Daniel
> 
>> On Dec 22, 2015, at 11:57 PM, Brian Gesiak via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello all,
>> 
>> I've been referring to the project hosted at
>> https://github.com/apple/swift-corelibs-xctest as
>> "swift-corelibs-xctest", and the project shipped alongside Xcode 7.2
>> as "Apple XCTest".
>> 
>> What are the canonical names for these projects? I'd like to agree on
>> common terminology to avoid confusion in the future.
>> 
>> Over the past few weeks I've seen several names for
>> https://github.com/apple/swift-corelibs-xctest:
>> 
>> - Open source XCTest
>> - Swift XCTest
>> - Linux XCTest
>> - swift-corelibs-xctest
>> 
>> And several names for the XCTest framework shipped alongside Xcode:
>> 
>> - Darwin XCTest
>> - Apple XCTest
>> 
>> How do you refer to these projects? What do you think is the simplest
>> way to refer to them, in a way that clearly differentiates them?
>> 
>> Personally, I prefer calling them "swift-corelibs-xctest" and "Apple
>> XCTest", although I do think that "swift-corelibs-xctest" is a
>> mouthful.
>> 
>> - Brian Gesiak
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Equality, etc in Foundation

[Tony Parker via swift-corelibs-dev]

Hi Luke,

Your proposed fix seems reasonable to me. Did you submit it as a PR too?

Thanks,
- Tony

> On Dec 29, 2015, at 11:28 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Proposed fix:
> 
> https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7
>  
> 
> 
> Also tracking in [SR-414].
> 
>> On 30 Dec 2015, at 6:15 PM, Luke Howard via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> import SwiftFoundation
>> 
>> let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>> "https://www.example.com "))!
>> let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>> "https://www.example.com "))!
>> 
>> print("\(url1.isEqual(url2))")
>> print("\(url1 == url2)")
>> 
> 
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Equality, etc in Foundation

[Tony Parker via swift-corelibs-dev]

Cool, thanks Philippe and Luke!

- Tony

> On Jan 4, 2016, at 12:59 PM, Philippe Hausler  wrote:
> 
> Actually I think we already got this one integrated.
> 
>> On Jan 4, 2016, at 12:58 PM, Tony Parker via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Luke,
>> 
>> Your proposed fix seems reasonable to me. Did you submit it as a PR too?
>> 
>> Thanks,
>> - Tony
>> 
>>> On Dec 29, 2015, at 11:28 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Proposed fix:
>>> 
>>> https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7
>>>  
>>> 
>>> 
>>> Also tracking in [SR-414].
>>> 
 On 30 Dec 2015, at 6:15 PM, Luke Howard via swift-corelibs-dev 
 mailto:swift-corelibs-dev@swift.org>> wrote:
 
 import SwiftFoundation
 
 let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
 "https://www.example.com "))!
 let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
 "https://www.example.com "))!
 
 print("\(url1.isEqual(url2))")
 print("\(url1 == url2)")
 
>>> 
>>> --
>>> www.lukehoward.com 
>>> soundcloud.com/lukehoward 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

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

Re: [swift-corelibs-dev] Equality, etc in Foundation

[Philippe Hausler via swift-corelibs-dev]

Actually I think we already got this one integrated.

> On Jan 4, 2016, at 12:58 PM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Luke,
> 
> Your proposed fix seems reasonable to me. Did you submit it as a PR too?
> 
> Thanks,
> - Tony
> 
>> On Dec 29, 2015, at 11:28 PM, Luke Howard via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Proposed fix:
>> 
>> https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7
>>  
>> 
>> 
>> Also tracking in [SR-414].
>> 
>>> On 30 Dec 2015, at 6:15 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> import SwiftFoundation
>>> 
>>> let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>>> "https://www.example.com "))!
>>> let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>>> "https://www.example.com "))!
>>> 
>>> print("\(url1.isEqual(url2))")
>>> print("\(url1 == url2)")
>>> 
>> 
>> --
>> www.lukehoward.com 
>> soundcloud.com/lukehoward 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] #if __CORELIBS_FOUNDATION__

[Tony Parker via swift-corelibs-dev]

Hi Drew,

This difference is a consequence of the lack of bridging between types like 
String and NSString.

If this API returned [String : AnyObject], then the dictionary could not 
contain String (because String is not an object).

This is something we will have to fix up in some comprehensive way in both 
Darwin and CoreLibs Foundation, but there is no answer yet.

In this particular case, how would you use the #if? Any should be source 
compatible with AnyObject, since Any is a superset of AnyObject, right?

- Tony

> On Jan 1, 2016, at 11:26 PM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> Hi folks,
> 
> I notice that swift-corelibs-foundation is (apparently) deliberately 
> incompatible with Darwin Foundation 
> (https://github.com/apple/swift-corelibs-foundation/blame/master/Foundation/NSFileManager.swift#L324
>  
> )
>  at least for the immediate future.
> 
> I'm wondering if we can get an #if that would let me write conditional code.
> 
> Obviously the "real" answer is to fix the bugs, but (at least on my side) 
> that will happen a lot faster if I "can" easily build the same codebase 
> against corelibs-foundation and darwin-foundation.
> 
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] CChar vs Int8

[Tony Parker via swift-corelibs-dev]

Hi Luke,

> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
> e.g.:
> var UTF8String: UnsafePointer 
>   
> >
>  { get }
> I don’t know if/when Swift will be ported to a platform where the character 
> type is unsigned but perhaps it would be good to update these to take CChar 
> instead?
> 
> — Luke
> 

I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
anyway. The Objective-C code uses char:

@property (nullable, readonly) __strong const char *UTF8String 
NS_RETURNS_INNER_POINTER;// Convenience to return null-terminated UTF8 
representation

- (nullable instancetype)initWithUTF8String:(const char *)nullTerminatedCString;

- Tony

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

Re: [swift-corelibs-dev] CChar vs Int8

[Philippe Hausler via swift-corelibs-dev]

No C strings import as UnsafePointer for some reason; they all import as 
Int8

e.g.
public func pthread_setname_np(_: UnsafePointer) -> Int32


> On Jan 4, 2016, at 1:20 PM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Luke,
> 
>> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
>> e.g.:
>> var UTF8String: UnsafePointer 
>> >  
>> >
>>  { get }
>> I don’t know if/when Swift will be ported to a platform where the character 
>> type is unsigned but perhaps it would be good to update these to take CChar 
>> instead?
>> 
>> — Luke
>> 
> 
> I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
> anyway. The Objective-C code uses char:
> 
> @property (nullable, readonly) __strong const char *UTF8String 
> NS_RETURNS_INNER_POINTER;  // Convenience to return null-terminated UTF8 
> representation
> 
> - (nullable instancetype)initWithUTF8String:(const char 
> *)nullTerminatedCString;
> 
> - Tony
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] CChar vs Int8

[Luke Howard via swift-corelibs-dev]

OK, I filed [SR-466] as a compiler issue. If the behaviour changes and that 
flows through to Darwin Foundation, we can update the open source one...

— Luke

> On 5 Jan 2016, at 8:21 AM, Philippe Hausler  wrote:
> 
> No C strings import as UnsafePointer for some reason; they all import 
> as Int8
> 
> e.g.
> public func pthread_setname_np(_: UnsafePointer) -> Int32
> 
> 
>> On Jan 4, 2016, at 1:20 PM, Tony Parker via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Luke,
>> 
>>> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
>>> e.g.:
>>> var UTF8String: UnsafePointer 
>>> >>  
>>> >
>>>  { get }
>>> I don’t know if/when Swift will be ported to a platform where the character 
>>> type is unsigned but perhaps it would be good to update these to take CChar 
>>> instead?
>>> 
>>> — Luke
>>> 
>> 
>> I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
>> anyway. The Objective-C code uses char:
>> 
>> @property (nullable, readonly) __strong const char *UTF8String 
>> NS_RETURNS_INNER_POINTER; // Convenience to return null-terminated UTF8 
>> representation
>> 
>> - (nullable instancetype)initWithUTF8String:(const char 
>> *)nullTerminatedCString;
>> 
>> - Tony
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

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

Re: [swift-corelibs-dev] Inconsistencies between Foundation APIs

[Tony Parker via swift-corelibs-dev]

Great, sounds good. If you ever notice a divergence, feel free to either file a 
bug or submit a PR that adds the comment. I don’t want to lose track of these 
things.

- Tony

> On Jan 4, 2016, at 11:55 AM, Ian Ynda-Hummel  wrote:
> 
> Got it. I've seen the experimental thing elsewhere in the code. I'll work 
> under the assumption that inconsistencies are experimental and I'll open bugs 
> for things that are inconsistent but not marked as such.
> 
> On Mon, Jan 4, 2016 at 2:51 PM Tony Parker  > wrote:
> Hi Ian,
> 
> Any place where the API differs should be marked with a comment like this:
> 
> /// - Experiment: This is a draft API currently under consideration for 
> official import into Foundation
> 
> If not, then we found some place that we either need to change or propose a 
> change for. We can track those with bugs on bugs.swift.org 
> . Most of the ‘Experiment’ APIs are something we have 
> no alternative but to change, though.
> 
> Thanks for your work on this,
> - Tony
> 
> 
>> On Dec 21, 2015, at 5:39 PM, Ian Ynda-Hummel via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
> 
>> I've been working on SR-276  and I'm 
>> finding a fair amount of inconsistencies between corelib Foundation and OS X 
>> Foundation. It seems to be most common with optionality of return values. 
>> e.g., in NSURL
>> 
>> corelib:
>> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL?
>> 
>> OS X:
>> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL
>> 
>> That particular case seems to be a difference in the treatment of the return 
>> value from CFURL
>> 
>>public func CFURLCreateCopyAppendingPathComponent(allocator: 
>> CFAllocator!, _ url: CFURL!, _ pathComponent: CFString!, _ isDirectory: 
>> Bool) -> CFURL!
>> 
>> Which briefly looking appears to be the same between corelib and OS X.
>> 
>> I'm not sure what the best way forward on these things is, though, as the 
>> corelib versions have seemed consistently improved, but presumably we still 
>> want maintain compatibility. Anyone have ideas?
> 
>>  ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 

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

Re: [swift-corelibs-dev] LazySequenceType: make prefix return a lazy collection

[Tony Parker via swift-corelibs-dev]

Hi Mark,

I’m going to loop in the swift-dev list for this question.

- Tony

> On Jan 4, 2016, at 5:15 AM, Mark Aron Szulyovszky via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I came across hit issue while chaining filter() and prefix() on lazy 
> sequences:
> https://bugs.swift.org/browse/SR-461 
> 
> And started wondering if it would be more consistent if 
> lazy.filter().prefix() returned a custom LazySequenceType 
> instead of Slice>>.
> 
> That way lazy.filter().prefix() could be used to chain pure lazy operations, 
> which can be actually quite useful in some cases.
> 
> I understand that this has implications, and it would make prefix() less 
> consistent in terms of return type, but it would eliminate confusion like 
> SR-461 .
> Also, this wouldn't be a much different than how how lazy.filter() is 
> implemented, since it also returns a custom LazySequenceType instead of 
> SequenceType.
> 
> Has this been considered before? Would there be any cases where this would 
> create unintended side effects?
> As far as I see, it wouldn't change the meaning of prefix(), only would it 
> extend its usefulness. 
> 
> I submitted a PR to the SwiftSequence library that demonstrates the 
> implementation of this: 
> https://github.com/itchingpixels/SwiftSequence/commit/26101e5aec6c266048bbad4db7b44b9c453f07ca
>  
> 
> 
> And I'm happy to contribute to contribute it to stdlib if people find it 
> useful.
> 
> Thanks a lot!
> 
> Mark
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] corelibs-xctest + swiftpm

[Tony Parker via swift-corelibs-dev]

Hi Keith,

Also - the Xcode project is provided for development ease-of-use only. This 
version of XCTest is only for non-Darwin platforms, and that builds with the 
simple shell script that is in the root directory (build_script.py).

- Tony

> On Jan 4, 2016, at 9:19 AM, Daniel Dunbar via swift-corelibs-dev 
>  wrote:
> 
> I think this makes sense (and commented in your PR). For now we will still 
> need the manual build process because we need XCTest to build first in CI, so 
> that we can use it in building/testing the package manager itself, but it 
> certainly makes sense to shoot for it to just be yet another package.
> 
> - Daniel
> 
>> On Dec 31, 2015, at 11:42 AM, Keith Smiley via swift-corelibs-dev 
>>  wrote:
>> 
>> Hey all,
>> 
>> I was working on integrating a project with corelibs-xctest and I noticed 
>> that
>> it doesn't currently support building with swiftpm and instead provides
>> `.xcodeproj` which generates a `.framework`. Is there any future plan to also
>> include a `Package.swift` so that user's could build it either way? Because 
>> of
>> how simple corelibs-xctest is this is just a matter of including a barebones
>> `Package.swift` and moving the source files.
>> 
>> 
>> Thanks!
>> 
>> --
>> Keith Smiley
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[swift-corelibs-dev] NSRegularExpression implementation

[Lukas Stabe via swift-corelibs-dev]

I have been thinking about trying to work on NSRegularExpression in 
corelibs-foundation, although I am not yet sure I’ll have time for it.

If I were to attempt it, am I correct in assuming that it should be based on 
icus (u)regex.h? I have not found any Regex support in CoreFoundation.

— Lukas
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev