Philosophy question: Foundation and Standard Library


(Erica Sadun) #1

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?

Thanks, -- E


(Chris Lattner) #2

Hi Erica,

I don’t see any specific reason to merge the stdlib and Foundation together - it seems like Foundation depending on the swift stdlib is proper layering. Lets look at the mission of both of these libraries:

For the Swift standard library, we want it to stay focused on the lowest-level “language support” primitives that includes things like Int, Array, Dictionary, OptionSet and the stuff they depend on (sequences etc). Even though they are implemented in the stdlib, I consider to be part of the the language. While we may elect to allow some minor scope creep, this will be carefully scrutinized and needs to be strongly justified.

For Foundation, there may be differing short-term and long-term answers here. In the short-term, the corelibs projects have a very specific focus, which is to enable cross-platform Swift development by making common Foundation APIs available on other platforms. This is a pretty huge project, so it is important that we keep focused on making this happen, even though folks have the natural inclination to do “new” things as well.

In this short term, I see SwiftPM as a great solution to avoid having to cram “everything interesting” into the standard library or Foundation. Once SwiftPM is ready, there should be very little downside to something being a package hosted on github or elsewhere.

In the longer term, we’ll have to see what happens, and make a decision that makes sense given the direction the project takes. We may decide to start adding new functionality to Foundation that doesn’t exist on Apple platforms yet (with the understanding that they will adopt it as well). We may decide to “standardize” new corelibs from existing popular packages, if they are outside of the scope of Foundation (totally random example: perhaps a web templating framework).

Putting something into the standard Swift distribution (instead of it being an independent package) comes with pros and cons. On the positive side, we want an official Swift release (e.g. "Swift 3.0”) to provide a consistent set of APIs out of the box that are guaranteed to be there. Getting your cool thing into the Swift distro guarantees that it will be available everywhere. On the downside, this is a bad way to go for rapidly evolving APIs in multiple ways: first, Swift has relatively infrequent updates (e.g. twice a year at current cadence) so it will take a long time to get changes out. Second, *changing* an API included in the Swift distribution will be comparatively hard. Instead of bumping the major version number of a package, it will have to go through a (TBD) lengthy deprecation process that will likely span multiple years.

In any case, we’ll figure it out as we go. We don’t have all the answers, and we’re learning too.

-Chris

···

On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?


(Félix Cloutier) #3

My understanding is that Foundation closely maps to the ObjC Foundation framework.

Félix

···

Le 31 déc. 2015 à 17:54:39, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?

Thanks, -- E

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


(Erica Sadun) #4

Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

Second, is how to push on what to add -- particularly for integrating proposals from the rich libraries of other languages. I'm interpreting what you wrote as that a standard library should be as flexible and widely applicable as possible while being implemented with the fewest possible moving parts ("stay focused on the lowest-level “language support” primitives")

This is counter to having to cram everything interesting into the standard library or Foundation but opens the possibility of creating standard Ruby-esque, Rust-esque, Haskell-esque, etc. packages, right? I'm going to take a wild guess that these latter items would have to be self organizing and fall outside the umbrella of Swift and Swift-Evolution. For this bit, I'm going to defer to Kevin, etc for figuring out what would be awesome to add in.

-- E

···

On Jan 1, 2016, at 1:46 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?

Hi Erica,

I don’t see any specific reason to merge the stdlib and Foundation together - it seems like Foundation depending on the swift stdlib is proper layering. Lets look at the mission of both of these libraries:

For the Swift standard library, we want it to stay focused on the lowest-level “language support” primitives that includes things like Int, Array, Dictionary, OptionSet and the stuff they depend on (sequences etc). Even though they are implemented in the stdlib, I consider to be part of the the language. While we may elect to allow some minor scope creep, this will be carefully scrutinized and needs to be strongly justified.

For Foundation, there may be differing short-term and long-term answers here. In the short-term, the corelibs projects have a very specific focus, which is to enable cross-platform Swift development by making common Foundation APIs available on other platforms. This is a pretty huge project, so it is important that we keep focused on making this happen, even though folks have the natural inclination to do “new” things as well.

In this short term, I see SwiftPM as a great solution to avoid having to cram “everything interesting” into the standard library or Foundation. Once SwiftPM is ready, there should be very little downside to something being a package hosted on github or elsewhere.

In the longer term, we’ll have to see what happens, and make a decision that makes sense given the direction the project takes. We may decide to start adding new functionality to Foundation that doesn’t exist on Apple platforms yet (with the understanding that they will adopt it as well). We may decide to “standardize” new corelibs from existing popular packages, if they are outside of the scope of Foundation (totally random example: perhaps a web templating framework).

Putting something into the standard Swift distribution (instead of it being an independent package) comes with pros and cons. On the positive side, we want an official Swift release (e.g. "Swift 3.0”) to provide a consistent set of APIs out of the box that are guaranteed to be there. Getting your cool thing into the Swift distro guarantees that it will be available everywhere. On the downside, this is a bad way to go for rapidly evolving APIs in multiple ways: first, Swift has relatively infrequent updates (e.g. twice a year at current cadence) so it will take a long time to get changes out. Second, *changing* an API included in the Swift distribution will be comparatively hard. Instead of bumping the major version number of a package, it will have to go through a (TBD) lengthy deprecation process that will likely span multiple years.

In any case, we’ll figure it out as we go. We don’t have all the answers, and we’re learning too.

-Chris


(Trent Nadeau) #5

Speaking of release cadence, do you think that Swift could transition to
the release train model (i.e., staged release, beta, and nightly) once
source and ABI compatibility are both established? That would allow a
quicker cadence and more testing of new library and language features. It's
seems to be working well with Rust so far, at least.

···

On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
> Under what criteria should we propose moving items into the standard
library and out from the standard library into Swift Foundation? Or will
these things eventually merge and become one grand unified module sometime
in the distant future?

Hi Erica,

I don’t see any specific reason to merge the stdlib and Foundation
together - it seems like Foundation depending on the swift stdlib is proper
layering. Lets look at the mission of both of these libraries:

For the Swift standard library, we want it to stay focused on the
lowest-level “language support” primitives that includes things like Int,
Array, Dictionary, OptionSet and the stuff they depend on (sequences etc).
Even though they are implemented in the stdlib, I consider to be part of
the the language. While we may elect to allow some minor scope creep, this
will be carefully scrutinized and needs to be strongly justified.

For Foundation, there may be differing short-term and long-term answers
here. In the short-term, the corelibs projects have a very specific focus,
which is to enable cross-platform Swift development by making common
Foundation APIs available on other platforms. This is a pretty huge
project, so it is important that we keep focused on making this happen,
even though folks have the natural inclination to do “new” things as well.

In this short term, I see SwiftPM as a great solution to avoid having to
cram “everything interesting” into the standard library or Foundation.
Once SwiftPM is ready, there should be very little downside to something
being a package hosted on github or elsewhere.

In the longer term, we’ll have to see what happens, and make a decision
that makes sense given the direction the project takes. We may decide to
start adding new functionality to Foundation that doesn’t exist on Apple
platforms yet (with the understanding that they will adopt it as well). We
may decide to “standardize” new corelibs from existing popular packages, if
they are outside of the scope of Foundation (totally random example:
perhaps a web templating framework).

Putting something into the standard Swift distribution (instead of it
being an independent package) comes with pros and cons. On the positive
side, we want an official Swift release (e.g. "Swift 3.0”) to provide a
consistent set of APIs out of the box that are guaranteed to be there.
Getting your cool thing into the Swift distro guarantees that it will be
available everywhere. On the downside, this is a bad way to go for rapidly
evolving APIs in multiple ways: first, Swift has relatively infrequent
updates (e.g. twice a year at current cadence) so it will take a long time
to get changes out. Second, *changing* an API included in the Swift
distribution will be comparatively hard. Instead of bumping the major
version number of a package, it will have to go through a (TBD) lengthy
deprecation process that will likely span multiple years.

In any case, we’ll figure it out as we go. We don’t have all the answers,
and we’re learning too.

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

--
Trent Nadeau


(Chris Lattner) #6

Speaking of release cadence, do you think that Swift could transition to the release train model (i.e., staged release, beta, and nightly) once source and ABI compatibility are both established? That would allow a quicker cadence and more testing of new library and language features. It's seems to be working well with Rust so far, at least.

Anything is possible, we’re always open to good ideas.

-Chris

···

On Jan 1, 2016, at 12:56 PM, Trent Nadeau <tanadeau@gmail.com> wrote:

On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?

Hi Erica,

I don’t see any specific reason to merge the stdlib and Foundation together - it seems like Foundation depending on the swift stdlib is proper layering. Lets look at the mission of both of these libraries:

For the Swift standard library, we want it to stay focused on the lowest-level “language support” primitives that includes things like Int, Array, Dictionary, OptionSet and the stuff they depend on (sequences etc). Even though they are implemented in the stdlib, I consider to be part of the the language. While we may elect to allow some minor scope creep, this will be carefully scrutinized and needs to be strongly justified.

For Foundation, there may be differing short-term and long-term answers here. In the short-term, the corelibs projects have a very specific focus, which is to enable cross-platform Swift development by making common Foundation APIs available on other platforms. This is a pretty huge project, so it is important that we keep focused on making this happen, even though folks have the natural inclination to do “new” things as well.

In this short term, I see SwiftPM as a great solution to avoid having to cram “everything interesting” into the standard library or Foundation. Once SwiftPM is ready, there should be very little downside to something being a package hosted on github or elsewhere.

In the longer term, we’ll have to see what happens, and make a decision that makes sense given the direction the project takes. We may decide to start adding new functionality to Foundation that doesn’t exist on Apple platforms yet (with the understanding that they will adopt it as well). We may decide to “standardize” new corelibs from existing popular packages, if they are outside of the scope of Foundation (totally random example: perhaps a web templating framework).

Putting something into the standard Swift distribution (instead of it being an independent package) comes with pros and cons. On the positive side, we want an official Swift release (e.g. "Swift 3.0”) to provide a consistent set of APIs out of the box that are guaranteed to be there. Getting your cool thing into the Swift distro guarantees that it will be available everywhere. On the downside, this is a bad way to go for rapidly evolving APIs in multiple ways: first, Swift has relatively infrequent updates (e.g. twice a year at current cadence) so it will take a long time to get changes out. Second, *changing* an API included in the Swift distribution will be comparatively hard. Instead of bumping the major version number of a package, it will have to go through a (TBD) lengthy deprecation process that will likely span multiple years.

In any case, we’ll figure it out as we go. We don’t have all the answers, and we’re learning too.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Dave Abrahams) #7

Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

It’s still a Swift 3 goal of the standard library to "make String awesome” (which entails many things from better usability to broader functionality). IMO an awesome string has to be in the base layer of the language, and can’t require pulling in Foundation. We’re not ready to start having this conversation in detail on swift-evolution yet, but I’m very much looking forward to discussing it with the community.

Second, is how to push on what to add -- particularly for integrating proposals from the rich libraries of other languages. I'm interpreting what you wrote as that a standard library should be as flexible and widely applicable as possible while being implemented with the fewest possible moving parts ("stay focused on the lowest-level “language support” primitives")

This is counter to having to cram everything interesting into the standard library or Foundation but opens the possibility of creating standard Ruby-esque, Rust-esque, Haskell-esque, etc. packages, right? I'm going to take a wild guess that these latter items would have to be self organizing and fall outside the umbrella of Swift and Swift-Evolution. For this bit, I'm going to defer to Kevin, etc for figuring out what would be awesome to add in.

-- E

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future?

Hi Erica,

I don’t see any specific reason to merge the stdlib and Foundation together - it seems like Foundation depending on the swift stdlib is proper layering. Lets look at the mission of both of these libraries:

For the Swift standard library, we want it to stay focused on the lowest-level “language support” primitives that includes things like Int, Array, Dictionary, OptionSet and the stuff they depend on (sequences etc). Even though they are implemented in the stdlib, I consider to be part of the the language. While we may elect to allow some minor scope creep, this will be carefully scrutinized and needs to be strongly justified.

For Foundation, there may be differing short-term and long-term answers here. In the short-term, the corelibs projects have a very specific focus, which is to enable cross-platform Swift development by making common Foundation APIs available on other platforms. This is a pretty huge project, so it is important that we keep focused on making this happen, even though folks have the natural inclination to do “new” things as well.

In this short term, I see SwiftPM as a great solution to avoid having to cram “everything interesting” into the standard library or Foundation. Once SwiftPM is ready, there should be very little downside to something being a package hosted on github or elsewhere.

In the longer term, we’ll have to see what happens, and make a decision that makes sense given the direction the project takes. We may decide to start adding new functionality to Foundation that doesn’t exist on Apple platforms yet (with the understanding that they will adopt it as well). We may decide to “standardize” new corelibs from existing popular packages, if they are outside of the scope of Foundation (totally random example: perhaps a web templating framework).

Putting something into the standard Swift distribution (instead of it being an independent package) comes with pros and cons. On the positive side, we want an official Swift release (e.g. "Swift 3.0”) to provide a consistent set of APIs out of the box that are guaranteed to be there. Getting your cool thing into the Swift distro guarantees that it will be available everywhere. On the downside, this is a bad way to go for rapidly evolving APIs in multiple ways: first, Swift has relatively infrequent updates (e.g. twice a year at current cadence) so it will take a long time to get changes out. Second, *changing* an API included in the Swift distribution will be comparatively hard. Instead of bumping the major version number of a package, it will have to go through a (TBD) lengthy deprecation process that will likely span multiple years.

In any case, we’ll figure it out as we go. We don’t have all the answers, and we’re learning too.

-Chris

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

-Dave

···

On Jan 1, 2016, at 2:13 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 1, 2016, at 1:46 PM, Chris Lattner <clattner@apple.com> wrote:
On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:


(Chris Lattner) #8

Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

Keep in mind that both are likely to be renamed as part of the swift 3 “renamification" effort. Tony and Dave A can comment a lot more about their plans there. That said, there are a number of aspects of the current Foundation interfaces that can be improved with various levels of trickery. One we’ve discussed in the past is for things like NSRegularExpression, which traffics a lot in UTF16 codepoint indexes. We’ve discussed introducing a typedef that gets imported as the Swift UTF16 view index, which would make a lot of things nice.

Beyond things like that, we can also discuss completely new APIs, or completely different ways to craft interfaces. However, I suspect the corelibs folks will treat those as a lot lower priority: the goal state there is much less clear, and we have a super-valuable target to shoot for in the short term.

As I mentioned before, our approach will surely evolve over time.

Second, is how to push on what to add -- particularly for integrating proposals from the rich libraries of other languages. I'm interpreting what you wrote as that a standard library should be as flexible and widely applicable as possible while being implemented with the fewest possible moving parts ("stay focused on the lowest-level “language support” primitives”)

I’m pretty sure I didn’t put it that way :-). Let me give you some examples: print and readLine are in the Swift standard library, but we don’t (and shouldn’t have) a fully featured I/O package (that should live at the Foundation level). Somewhere in between would be a “printf replacement” that would allow format control for print (this is something we’ve discussed a lot, but were blocked by missing language features in the swift 1 time, and didn’t have time in the swift 2 cycle). I suspect that simple formatting functionality could exist at the swift stdlib level, but it would be quite a debate :-)

In short, I don’t have a simple answer for you. However, it is always safe to start with a short email to swift-evolution saying “do you think this idea is in scope for the swift stdlib or not?”.

This is counter to having to cram everything interesting into the standard library or Foundation but opens the possibility of creating standard Ruby-esque, Rust-esque, Haskell-esque, etc. packages, right? I'm going to take a wild guess that these latter items would have to be self organizing and fall outside the umbrella of Swift and Swift-Evolution. For this bit, I'm going to defer to Kevin, etc for figuring out what would be awesome to add in.

I’m not sure what you mean when you reference those other languages’ packages, but yes, self-organization is a pretty big feature of SwiftPM packages. We’ve discussed having a centralized index and would love to see that happen (so long as it is opt-in and not required - we also want SwiftPM to be usable for non-public projects and code), someone just needs to step forward to drive the effort.

-Chris

···

On Jan 1, 2016, at 2:13 PM, Erica Sadun <erica@ericasadun.com> wrote:


(Rod Brown) #9

Please see response inline

- Rod

Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

I find this a very good point and points to something interesting with Swift Foundation.

Is it more important to maintain design closely similar to Objective-C foundation, or to push for a more "swift" design philosophy that may indeed push away from Objective C foundation?

We are essentially outlining some of the foundational (no pun intended) elements of Swift, and a clean, coherent design makes sense. That said, I suspect branching away from Objective-C Foundation may create confusion for developers who write both for Apple Platforms and for servers - "Am I using Swift Foundation, or Objective-C Foundation?"

I think some clarifications on direction would be helpful here before I consider diving in and helping with Swift Foundation (which does interest me a lot!)

···

On 2 Jan 2016, at 9:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Second, is how to push on what to add -- particularly for integrating proposals from the rich libraries of other languages. I'm interpreting what you wrote as that a standard library should be as flexible and widely applicable as possible while being implemented with the fewest possible moving parts ("stay focused on the lowest-level “language support” primitives")

This is counter to having to cram everything interesting into the standard library or Foundation but opens the possibility of creating standard Ruby-esque, Rust-esque, Haskell-esque, etc. packages, right? I'm going to take a wild guess that these latter items would have to be self organizing and fall outside the umbrella of Swift and Swift-Evolution. For this bit, I'm going to defer to Kevin, etc for figuring out what would be awesome to add in.

-- E


(Chris Lattner) #10

Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

I find this a very good point and points to something interesting with Swift Foundation.

Is it more important to maintain design closely similar to Objective-C foundation, or to push for a more "swift" design philosophy that may indeed push away from Objective C foundation?

Our goal is to pull the two together, so that Foundation ultimately feels 100% Swift native. This is one major reason that we’re doing corelibs-foundation the way we are in the first place, to force the design discussions to happen.

We plan to do this through a combination of improving how Swift imports Objective-C APIs (something that made a lot of progress in Swift 2, and should make at least some more progress in Swift 3) as well as by adding “more swifty” interfaces manually where it makes sense (e.g. through overlays). This is something you should discuss on a case by case basis with the corelibs folks, because there is no one blanket answer.

We are essentially outlining some of the foundational (no pun intended) elements of Swift, and a clean, coherent design makes sense. That said, I suspect branching away from Objective-C Foundation may create confusion for developers who write both for Apple Platforms and for servers - "Am I using Swift Foundation, or Objective-C Foundation?”

This would be a pretty big problem, defeating the goal of supporting cross-platform development with Swift.

-Chris

···

On Jan 1, 2016, at 3:32 PM, Rod Brown <rodney.brown6@icloud.com> wrote:


(Rod Brown) #11

Brilliant. Makes sense and seems to be a best-of-both-worlds approach.

- Rod

···

On 2 Jan 2016, at 3:16 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 1, 2016, at 3:32 PM, Rod Brown <rodney.brown6@icloud.com> wrote:
Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

I find this a very good point and points to something interesting with Swift Foundation.

Is it more important to maintain design closely similar to Objective-C foundation, or to push for a more "swift" design philosophy that may indeed push away from Objective C foundation?

Our goal is to pull the two together, so that Foundation ultimately feels 100% Swift native. This is one major reason that we’re doing corelibs-foundation the way we are in the first place, to force the design discussions to happen.

We plan to do this through a combination of improving how Swift imports Objective-C APIs (something that made a lot of progress in Swift 2, and should make at least some more progress in Swift 3) as well as by adding “more swifty” interfaces manually where it makes sense (e.g. through overlays). This is something you should discuss on a case by case basis with the corelibs folks, because there is no one blanket answer.

We are essentially outlining some of the foundational (no pun intended) elements of Swift, and a clean, coherent design makes sense. That said, I suspect branching away from Objective-C Foundation may create confusion for developers who write both for Apple Platforms and for servers - "Am I using Swift Foundation, or Objective-C Foundation?”

This would be a pretty big problem, defeating the goal of supporting cross-platform development with Swift.

-Chris


(Tony Parker) #12

Not that I need to say this, but I’ll chime in anyway with a big +1 to what Chris said. =)

Fortunately, the current code owners for swift-corelibs-foundation are the same people that work on Foundation for all of our other platforms. That means we’re in a great position to make Foundation great in Swift everywhere. As Chris said, we have a giant task of getting the fundamentals up and running without Objective-C, so that is our primary goal for Swift 3. However, we are interested in all kinds of improvements in the long term.

Thanks,
- Tony

···

On Jan 1, 2016, at 10:32 PM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:

Brilliant. Makes sense and seems to be a best-of-both-worlds approach.

- Rod

On 2 Jan 2016, at 3:16 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 1, 2016, at 3:32 PM, Rod Brown <rodney.brown6@icloud.com> wrote:
Thanks Chris. I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts. In particular, I'm considering two scenarios.

First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.)

I find this a very good point and points to something interesting with Swift Foundation.

Is it more important to maintain design closely similar to Objective-C foundation, or to push for a more "swift" design philosophy that may indeed push away from Objective C foundation?

Our goal is to pull the two together, so that Foundation ultimately feels 100% Swift native. This is one major reason that we’re doing corelibs-foundation the way we are in the first place, to force the design discussions to happen.

We plan to do this through a combination of improving how Swift imports Objective-C APIs (something that made a lot of progress in Swift 2, and should make at least some more progress in Swift 3) as well as by adding “more swifty” interfaces manually where it makes sense (e.g. through overlays). This is something you should discuss on a case by case basis with the corelibs folks, because there is no one blanket answer.

We are essentially outlining some of the foundational (no pun intended) elements of Swift, and a clean, coherent design makes sense. That said, I suspect branching away from Objective-C Foundation may create confusion for developers who write both for Apple Platforms and for servers - "Am I using Swift Foundation, or Objective-C Foundation?”

This would be a pretty big problem, defeating the goal of supporting cross-platform development with Swift.

-Chris

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