[swift-corelibs-dev] bridging (SR-138)

[Drew Crawford via swift-corelibs-dev]

I've noticed that e.g. String is not bridged to NSString.  The expected 
workaround seems to be calling .bridge() everywhere.

1.  Is there a plan for bridging e.g. String with NSString?
2.  Would it be appropriate to PR in the meantime e.g.

extension String {
public func cStringUsingEncoding(encoding: UInt) -> UnsafePointer 
{
return self.bridge().cStringUsingEncoding(encoding)
}
}

  3.  The README also says

> We will also drop the 'NS' prefix from all Foundation classes


...is that the resolution?  e.g what is currently class NSString will become 
instead extension String?  Is there a bug open for that?___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] bridging (SR-138)

[Keith Smiley via swift-corelibs-dev]

There's a mention of this in the "Issues" document here:

https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Issues.md#known-issues

That makes it sound like this isn't meant to be a long term limitation:

> In order to translate between these types, we have temporarily added a
> protocol to these types that allows them to be converted.

And:

> These limitations should hopefully be very short-term.

--
Keith Smiley

On 01/02, Drew Crawford via swift-corelibs-dev wrote:
> I've noticed that e.g. String is not bridged to NSString.  The expected 
> workaround seems to be calling .bridge() everywhere.
>
> 1.  Is there a plan for bridging e.g. String with NSString?
> 2.  Would it be appropriate to PR in the meantime e.g.
>
> extension String {
> public func cStringUsingEncoding(encoding: UInt) -> 
> UnsafePointer {
> return self.bridge().cStringUsingEncoding(encoding)
> }
> }
>
>   3.  The README also says
>
> > We will also drop the 'NS' prefix from all Foundation classes
>
>
> ...is that the resolution?  e.g what is currently class NSString will become 
> instead extension String?  Is there a bug open for that?

> ___
> 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] bridging (SR-138)

[Philippe Hausler via swift-corelibs-dev]

String is bridged it just is not yet implicitly converted via the compiler; we 
are missing certain functionality due to the compiler not supporting the objc 
code paths on linux.

The re-naming of swift classes exposed from Foundation will likely leave the 
class NSString still a thing (however it likely will have some special case of 
naming since there is a conflict between Foundation’s String and Swift’s String 
that is yet to be determined fully on how that will be done), so it is still a 
bit up-in-the-air on how that will be achieved. However since there are desired 
behavioral differences between NSString and String we cannot just wholesale 
make it an extension since some of the functions that apply to NSString don’t 
make much sense for String (e.g. characterAtIndex etc).

The bug you are probably looking for is: https://bugs.swift.org/browse/SR-138. 
Basically what we need is _ObjectTypeBridgeable to behave similarly to the type 
conversion portion of _ObjectiveCBridgeable. This would likely be primarily 
work in the compiler and also a bit of work in the stdlib for a few of the 
overlay extensions etc.


> On Jan 2, 2016, at 12:24 AM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> I've noticed that e.g. String is not bridged to NSString.  The expected 
> workaround seems to be calling .bridge() everywhere.
> 
> 1.  Is there a plan for bridging e.g. String with NSString?
> 2.  Would it be appropriate to PR in the meantime e.g.
> 
> extension String {
> public func cStringUsingEncoding(encoding: UInt) -> 
> UnsafePointer {
> return self.bridge().cStringUsingEncoding(encoding)
> }
> }
> 
>   3.  The README also says
> 
>> We will also drop the 'NS' prefix from all Foundation classes
> 
> 
> ...is that the resolution?  e.g what is currently class NSString will become 
> instead extension String?  Is there a bug open for that?
> 
> ___
> 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] relationship of CF

[Drew Crawford via swift-corelibs-dev]

I had a question about something I saw in the docs:

> A significant portion of the implementation of Foundation on Apple platforms 
> is provided by another framework called CoreFoundation (a.k.a. CF). CF is 
> written primarily in C and is very portable. Therefore we have chosen to use 
> it for the internal implementation of Swift Foundation where possible. As CF 
> is present on all platforms, we can use it to provide a common implementation 
> everywhere.

(emphasis added)

Is the intent of this paragraph to suggest that most PRs to 
swift-corelibs-foundation should be a C-language implementation to CF with a 
light Swift wrapper?  That goes against my intuition, but it "seems to be" a 
plain reading of the paragraph.

its justification about "all platforms" is also strange–I know CF "kind of" 
builds for Windows, but is anyone actually testing it there?  To make sure we 
aren't breaking it?  Or does "all platforms" mean something else here?

I feel like this paragraph is an opportunity to explain to a patch author how 
to structure their patch between use/maintenance/contributions to the CF layer 
vs the Swift layer.  I feel like it could do a much better job, but I don't 
understand what the design guidance actually is, so I can't fix it.





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

Re: [swift-corelibs-dev] relationship of CF

[Philippe Hausler via swift-corelibs-dev]

Responses inline:

> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> I had a question about something I saw in the docs:
> 
>> A significant portion of the implementation of Foundation on Apple platforms 
>> is provided by another framework called CoreFoundation (a.k.a. CF). CF is 
>> written primarily in C and is very portable. Therefore we have chosen to use 
>> it for the internal implementation of Swift Foundation where possible. As CF 
>> is present on all platforms, we can use it to provide a common 
>> implementation everywhere.
> 
> (emphasis added)
> 
> Is the intent of this paragraph to suggest that most PRs to 
> swift-corelibs-foundation should be a C-language implementation to CF with a 
> light Swift wrapper?  That goes against my intuition, but it "seems to be" a 
> plain reading of the paragraph.

I think the underlying intent is that we should use the right tools for the 
job; where it makes sense, even the standard library uses C++. Similarly some 
of the interfaces for ICU for example make much more sense to encapsulate with 
CF (and re-use some of the existing cross platform abstractions). Some classes 
will be a thin veneer on top of CF, where-as others will be a completely swift 
implementation. Take the two cases of NSCalendar and NSThread. CF provides some 
very hard to write (and hard to get right) implementations of calendrical math, 
even though I wrote a good portion of the NSCalendar swift implementation; I am 
definitely glad that there was an implementation I could fall back upon to deal 
with that logic. The counterpoint of NSThread; we could have wrapped up a 
CFThreadRef type object and bridged it across but It made sense to keep 
NSThread in the realm of Swift not only for a potential example of dealing with 
posix APIs for the community but also it just worked out more cleanly in my 
opinion.

I have not crunched the numbers but I have a gut feeling that a large majority 
of the pull requests have been mostly Swift implementations and only a few of 
them have been thin veneers on-top-of CF and even fewer have been changes to CF 
itself.

> 
> its justification about "all platforms" is also strange–I know CF "kind of" 
> builds for Windows, but is anyone actually testing it there?  To make sure we 
> aren't breaking it?  Or does "all platforms" mean something else here?

I know there have been efforts to port swift to FreeBSD and to new 
architectures like ARM-elf for things like Raspberry Pi, I would not be 
surprised that there are efforts to port to Android or Windows out there. 
Granted we do not have any CI provided by Apple to ensure not breaking these 
efforts but I think that the community will be interested in keeping these 
things running since a cross platform framework and language are really 
appealing (even Apple makes a few products for Android and Windows…)

As of current the Windows target is not held directly from the point at which 
this CF was cut from; so I would probably say “trust but verify” and I would 
not be surprised that there may be a few breaking points there that need to be 
re-looked at for that platform. I am certain that if someone took up a new 
target like Windows that would be met with great enthusiasm from all of the 
swift community. I was ecstatic when I saw that there was a FreeBSD port.

I think the one major thing to take under consideration is that alternate 
platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI 
that the swift project maintains. I think however if there is strong desire out 
there it would be interesting to have externally maintained build servers 
provided by the community to verify these targets. I am not in charge of that 
type of decision but I would definitely think that it would be an amiable goal 
and I would think that it would be worthwhile to discuss further.

> 
> I feel like this paragraph is an opportunity to explain to a patch author how 
> to structure their patch between use/maintenance/contributions to the CF 
> layer vs the Swift layer.  I feel like it could do a much better job, but I 
> don't understand what the design guidance actually is, so I can't fix it.
> 

Things that enter into CF territory will be things that we will consider with a 
very close eye on them because they will likely move up-stream into the 
CoreFoundation that ships with our current platforms so that the lifecycle 
completes back out to the exported version in the open-source side of it.  The 
Foundation part of the story is a bit more mutable since we have the 
Objective-C version that will still be maintained. That being said there is a 
very strong desire to keep these in parity; we may use some of the interfaces 
in the swift version to try out what people think of these APIs (most of these 
are marked with experimental, and if they are not we should either correct them 
to be the same or mark them as such). Furthermore the swift version will 
sometimes driv

Re: [swift-corelibs-dev] relationship of CF

[Dave Fenton via swift-corelibs-dev]

Given the educational angle that seems to be part of the mission of Swift, I 
was hoping that the Raspberry Pi port would be something the Swift project 
would directly integrate  and distribute 

-david

> On Jan 2, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> 
> Responses inline:
> 
>> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev 
>>  wrote:
>> 
>> I had a question about something I saw in the docs:
>> 
>>> A significant portion of the implementation of Foundation on Apple 
>>> platforms is provided by another framework called CoreFoundation (a.k.a. 
>>> CF). CF is written primarily in C and is very portable. Therefore we have 
>>> chosen to use it for the internal implementation of Swift Foundation where 
>>> possible. As CF is present on all platforms, we can use it to provide a 
>>> common implementation everywhere.
>> 
>> (emphasis added)
>> 
>> Is the intent of this paragraph to suggest that most PRs to 
>> swift-corelibs-foundation should be a C-language implementation to CF with a 
>> light Swift wrapper?  That goes against my intuition, but it "seems to be" a 
>> plain reading of the paragraph.
> 
> I think the underlying intent is that we should use the right tools for the 
> job; where it makes sense, even the standard library uses C++. Similarly some 
> of the interfaces for ICU for example make much more sense to encapsulate 
> with CF (and re-use some of the existing cross platform abstractions). Some 
> classes will be a thin veneer on top of CF, where-as others will be a 
> completely swift implementation. Take the two cases of NSCalendar and 
> NSThread. CF provides some very hard to write (and hard to get right) 
> implementations of calendrical math, even though I wrote a good portion of 
> the NSCalendar swift implementation; I am definitely glad that there was an 
> implementation I could fall back upon to deal with that logic. The 
> counterpoint of NSThread; we could have wrapped up a CFThreadRef type object 
> and bridged it across but It made sense to keep NSThread in the realm of 
> Swift not only for a potential example of dealing with posix APIs for the 
> community but also it just worked out more cleanly in my opinion.
> 
> I have not crunched the numbers but I have a gut feeling that a large 
> majority of the pull requests have been mostly Swift implementations and only 
> a few of them have been thin veneers on-top-of CF and even fewer have been 
> changes to CF itself.
> 
>> 
>> its justification about "all platforms" is also strange–I know CF "kind of" 
>> builds for Windows, but is anyone actually testing it there?  To make sure 
>> we aren't breaking it?  Or does "all platforms" mean something else here?
> 
> I know there have been efforts to port swift to FreeBSD and to new 
> architectures like ARM-elf for things like Raspberry Pi, I would not be 
> surprised that there are efforts to port to Android or Windows out there. 
> Granted we do not have any CI provided by Apple to ensure not breaking these 
> efforts but I think that the community will be interested in keeping these 
> things running since a cross platform framework and language are really 
> appealing (even Apple makes a few products for Android and Windows…)
> 
> As of current the Windows target is not held directly from the point at which 
> this CF was cut from; so I would probably say “trust but verify” and I would 
> not be surprised that there may be a few breaking points there that need to 
> be re-looked at for that platform. I am certain that if someone took up a new 
> target like Windows that would be met with great enthusiasm from all of the 
> swift community. I was ecstatic when I saw that there was a FreeBSD port.
> 
> I think the one major thing to take under consideration is that alternate 
> platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI 
> that the swift project maintains. I think however if there is strong desire 
> out there it would be interesting to have externally maintained build servers 
> provided by the community to verify these targets. I am not in charge of that 
> type of decision but I would definitely think that it would be an amiable 
> goal and I would think that it would be worthwhile to discuss further.
> 
>> 
>> I feel like this paragraph is an opportunity to explain to a patch author 
>> how to structure their patch between use/maintenance/contributions to the CF 
>> layer vs the Swift layer.  I feel like it could do a much better job, but I 
>> don't understand what the design guidance actually is, so I can't fix it.
> 
> Things that enter into CF territory will be things that we will consider with 
> a very close eye on them because they will likely move up-stream into the 
> CoreFoundation that ships with our current platforms so that the lifecycle 
> completes back out to the exported version in the open-source side of it.  
> The Foundation part of the story is a bit more mutable since

Re: [swift-corelibs-dev] relationship of CF

[Philippe Hausler via swift-corelibs-dev]

I think perhaps it might be worth something to investigate on what it would 
take to get these extra platforms integrated into CI as nodes to the Swift 
primary builders. As a note since we do target ARM as a primary platform for 
Darwin and we do target Linux as a primary platform, ARM linux is not a far 
stretch so the Pi is much more “supported” than other targets like the initial 
question of Windows code paths at the current moment.

Perhaps one of the compiler team can chime in since the packaging and automatic 
builds are their domain and not per-se mine.

> On Jan 2, 2016, at 1:57 PM, Dave Fenton via swift-corelibs-dev 
>  wrote:
> 
> Given the educational angle that seems to be part of the mission of Swift, I 
> was hoping that the Raspberry Pi port would be something the Swift project 
> would directly integrate  and distribute 
> 
> -david
> 
> On Jan 2, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> 
>> Responses inline:
>> 
>>> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> I had a question about something I saw in the docs:
>>> 
 A significant portion of the implementation of Foundation on Apple 
 platforms is provided by another framework called CoreFoundation (a.k.a. 
 CF). CF is written primarily in C and is very portable. Therefore we have 
 chosen to use it for the internal implementation of Swift Foundation where 
 possible. As CF is present on all platforms, we can use it to provide a 
 common implementation everywhere.
>>> 
>>> (emphasis added)
>>> 
>>> Is the intent of this paragraph to suggest that most PRs to 
>>> swift-corelibs-foundation should be a C-language implementation to CF with 
>>> a light Swift wrapper?  That goes against my intuition, but it "seems to 
>>> be" a plain reading of the paragraph.
>> 
>> I think the underlying intent is that we should use the right tools for the 
>> job; where it makes sense, even the standard library uses C++. Similarly 
>> some of the interfaces for ICU for example make much more sense to 
>> encapsulate with CF (and re-use some of the existing cross platform 
>> abstractions). Some classes will be a thin veneer on top of CF, where-as 
>> others will be a completely swift implementation. Take the two cases of 
>> NSCalendar and NSThread. CF provides some very hard to write (and hard to 
>> get right) implementations of calendrical math, even though I wrote a good 
>> portion of the NSCalendar swift implementation; I am definitely glad that 
>> there was an implementation I could fall back upon to deal with that logic. 
>> The counterpoint of NSThread; we could have wrapped up a CFThreadRef type 
>> object and bridged it across but It made sense to keep NSThread in the realm 
>> of Swift not only for a potential example of dealing with posix APIs for the 
>> community but also it just worked out more cleanly in my opinion.
>> 
>> I have not crunched the numbers but I have a gut feeling that a large 
>> majority of the pull requests have been mostly Swift implementations and 
>> only a few of them have been thin veneers on-top-of CF and even fewer have 
>> been changes to CF itself.
>> 
>>> 
>>> its justification about "all platforms" is also strange–I know CF "kind of" 
>>> builds for Windows, but is anyone actually testing it there?  To make sure 
>>> we aren't breaking it?  Or does "all platforms" mean something else here?
>> 
>> I know there have been efforts to port swift to FreeBSD and to new 
>> architectures like ARM-elf for things like Raspberry Pi, I would not be 
>> surprised that there are efforts to port to Android or Windows out there. 
>> Granted we do not have any CI provided by Apple to ensure not breaking these 
>> efforts but I think that the community will be interested in keeping these 
>> things running since a cross platform framework and language are really 
>> appealing (even Apple makes a few products for Android and Windows…)
>> 
>> As of current the Windows target is not held directly from the point at 
>> which this CF was cut from; so I would probably say “trust but verify” and I 
>> would not be surprised that there may be a few breaking points there that 
>> need to be re-looked at for that platform. I am certain that if someone took 
>> up a new target like Windows that would be met with great enthusiasm from 
>> all of the swift community. I was ecstatic when I saw that there was a 
>> FreeBSD port.
>> 
>> I think the one major thing to take under consideration is that alternate 
>> platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI 
>> that the swift project maintains. I think however if there is strong desire 
>> out there it would be interesting to have externally maintained build 
>> servers provided by the community to verify these targets. I am not in 
>> charge of that type of decision but I would definitely thi

[swift-corelibs-dev] CChar vs Int8

[Luke Howard via swift-corelibs-dev]

Many Foundation APIs use Int8 instead of CChar when representing C strings, 
e.g.:
var UTF8String: UnsafePointer 
https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_Int8_Structure/index.html#//apple_ref/swift/struct/s:VSs4Int8>>
 { 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___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev