[swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

Austin Zheng austinzheng at gmail.com
Sun Feb 21 14:13:46 CST 2016


Agreed. I created a GitHub organization
('swift-stdlib-opensource-collaborators'), and will try to invite the
non-Apple ('outsider') folks to join. Once that's happened, maybe Shawn can
move his fork under the organization, or one of us can fork the repo again.
I'm not very familiar with how orgs work, but I assume we'll be able to
push to the fork with minimal friction, and then occasionally the org
itself can make PRs to Swift proper?

Once we get this worked out I'll begin working through the first part of
Dave's tasklist.

Best,
Austin



On Sun, Feb 21, 2016 at 9:57 AM, Shawn Erickson <shawnce at gmail.com> wrote:

> First I see that Dmitri G. appears to be most involved with this yet in
> the other thread I see Dmitri H. being copied. So which/both of you
> involved with this effort? ...or are you one and the same given the
> similarity of the name? /me hopes he doesn't look like a total idiot now
>
> Second given commit access limits it may make sense for those of us on the
> "outside" to work in same fork (e.g. added as collaborators)? It may help
> avoid pull request overhead between us while work is underway? My github
> identity is "shawnce". I have a fork created
> https://github.com/shawnce/swift if so desired to use that as the sandbox
> (set default branch to swift-3-indexing-model). ...looking for guidance on
> how best to make things work efficiently.
>
> I am digging into
> https://github.com/apple/swift/blob/master/test/Prototypes/CollectionsMoveIndices.swift to
> understand the scope of the work involved.
>
> Anyway I am looking at the current state of the code and I see things like
> the following...
>    @available(*, unavailable, renamed="MutableCollection")
>     public typealias MutableCollectionType = MutableCollection
> ...so it looks like the use of Type is being dropped in the updated naming
> methodology? So this obviously implies... right?
> //     [new]   protocol BidirectionalCollection : Collection {}
> //     [new]   protocol RandomAccessCollection : BidirectionalCollection
>
> I expect additional – hopefully less mundane :) – questions to popup as I
> dig into things.
>
> -Shawn
>
> As reference Dave outlined the following in the other email thread...
> -----
> Okay, I've up a branch for you guys: swift-3-indexing-model.
>
> * You can submit pull requests against that.
>
> * There are corresponding branches in the swift-llvm and swift-clang
>   repos that this branch will build/test against.
>
> * The branch is based on swift-3-api-guidelines, where we're doing all
>   the renaming work associated with the new guidelines; we expect to
>   merge that branch into master in a few days, so basing the indexing model
>   work on it should reduce conflicts when we merge this work.
>
> Most of the stdlib team is currently occupied with other fires, but we
> want to move on to work on this ASAP.  If it's possible for you guys to
> get it started in the meantime, that would be truly awesome.
> Unfortunately the hardest part is right at the beginning.
>
> The first step is to make the minimal changes required to get the
> standard library to build after replacing the Collection protocol with
> the three shown in the prototype.  That step may not be very
> parallelizable and might require either close coordination or for one of
> you to do it alone.  Tests will be horribly broken at this point, and
> you may have even commented out parts of the standard library, so this
> step requires intestinal fortitude.
>
> If parts of the library have been disabled in step 1, next you can split
> up the work of getting the whole library to work.
>
> At this point you should be able to mark the old Index protocols
> @unavailable and move on to fixing tests.
> -----
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160221/41045942/attachment.html>


More information about the swift-dev mailing list