On Jan 1, 2016, at 2:13 PM, Erica Sadun <[email protected]> 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.)
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
