Sent from my iPhone
> On Jun 13, 2017, at 6:05 AM, Maik Koslowski <[email protected]> wrote: > > It’s definitely more effort needed than i thought at first. I can create an > API suggestion, but that will take a while. Since this will happen in Swift 5 > or later, we will have enough time anyway. Right. There are staging possibilities here... OrderedSet could exist and even be bridgeable with NSOrderedSet, but we wouldn't want to take a source-breaking change to affected Objective-C imported APIs until Swift 5 (if at all! It's something to discuss). > Does it make sense to create a proposal on GitHub or should I wait at least > for Swift 5 since this is out of scope for Swift 4? We are in a bit of a dead zone while we wrap up Swift 4. It's fine to prepare a draft proposal for discussion, but we won't merge the proposal into the main Swift-evolution repo or run a review until the core team scopes post-Swift 4 releases. - Doug > > - Maik > >>> Am 12.06.2017 um 18:35 schrieb Douglas Gregor <[email protected]>: >>> >>> >>> On Jun 10, 2017, at 8:42 AM, Tony Parker <[email protected]> wrote: >>> >>> This is still something I want to do, but I suspect it will require some >>> coordination work with the NSOrderedSet ref type in Foundation. >>> >>> Also, as Doug says, there is a larger question too of how we make source >>> breaking changes like this in Swift 5 (I think we’re probably out of runway >>> for Swift 4 at this point). >> >> Definitely too late for Swift 4. >> >> Whether we should do it in Swift 5 depends on the source-compatibility >> story. The Swift 4 compiler has the ability to present imported types to >> Swift 3.2 differently from Swift 4, which we used to stage in (e.g.) >> subclass existentials and SDK changes. We could conceivably do the same for >> NSOrderedSet <-> OrderedSet bridging, suppressing bridging of NSOrderedSet >> in imported APIs for Swift <= 4. >> >>> We would want to bridge this in from the SDK, but if it follows the pattern >>> of our value types, we need to make API changes from the ref type to make >>> it fit in correctly with Swift-only concepts like the Collection protocols. >> >> Sure, we’d need to design it to fit well with the standard library and >> provide the APIs people expect from NSOrderedSet. >> >> - Doug >> >>> - Tony >>> >>>>> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Let me try to redirect this conversation, if I may. >>>>> >>>>> As far as I can tell, SE-0069 states plainly that the plan of record is >>>>> to offer a value type called OrderedSet in Foundation, but resources to >>>>> design and implement were not then available. >>>>> >>>>> So, little point in having a vote as to whether one is in favor of >>>>> OrderedSet or not. In my view, the questions to be answered are: >>>>> >>>>> For the core team– >>>>> >>>>> * Is it still the plan to offer value types postponed from SE-0069 as a >>>>> future addition to Foundation? >>>> >>>> *I* think it’s still a good idea, and I suspect that others on the core >>>> team will agree. >>>> >>>>> * If so, is that a priority in the Swift 5 timeframe, and how can the >>>>> community help to bring about this addition? >>>> >>>> I wouldn’t consider it a “priority”, in the sense that I can’t imagine >>>> anything in Swift 5 that would absolutely require us to introduce this >>>> functionality in that time frame. It’s a bit of a >>>> nice-to-have-at-any-point, noting of course that bridging NSOrderedSet in >>>> existing APIs is a nontrivial source-breaking change. >>>> >>>> Having a proposed API and implementation on hand makes it easier to add >>>> this functionality, of course. >>>> >>>>> If not, for the whole community– >>>>> >>>>> * Is it wise to implement such a type in the standard library? Should we >>>>> simply bring over the native implementation from Swift Package Manager? >>>>> What are the implications for bridging? >>>> >>>> Obviously, we’d want an efficient copy-on-write, native implementation; >>>> the Swift Package Manager implementation is a bit more bare-bones than >>>> we’d want: absolute performance matters, so having a separate Set + Array >>>> in the struct probably isn’t good enough. Bridging performance matters, so >>>> we’d probably want the one-pointer representation like array uses where >>>> the pointer can be vended directly to Objective-C. >>>> >>>> - Doug >>>> >>>>>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> +1 for ordered set and dictionary, and please add ordered dictionary in >>>>>> ObjC as well. >>>>>> >>>>>> Envoyé de mon iPhone >>>>>> >>>>>>> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution >>>>>>> <[email protected]> a écrit : >>>>>>> >>>>>>> +1, and would also like to see OrderedDictionary as well. >>>>>>> >>>>>>>> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> I would be in favor of it; there have been a few times (including Core >>>>>>>> Data, as you mentioned) where I would have used it had it been >>>>>>>> available. >>>>>>>> >>>>>>>> >>>>>>>> Jeff Kelley >>>>>>>> >>>>>>>> [email protected] | @SlaunchaMan | jeffkelley.org >>>>>>>> >>>>>>>>> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> in the past there have been a few requests for an OrderedSet >>>>>>>>> implementation in Swift. In the proposal >>>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md >>>>>>>>> was mentioned that the OrderedSet will be considered for the feature. >>>>>>>>> >>>>>>>>> However, since then there were a few discussions on OrderedSet but it >>>>>>>>> doesn’t get much attention and there wasn’t any comment about it from >>>>>>>>> the swift team. >>>>>>>>> >>>>>>>>> I want to bring up some points, why an OrderedSet is needed in the >>>>>>>>> base library. >>>>>>>>> >>>>>>>>> 1. CoreData is probably the most obvious place where people would use >>>>>>>>> an ordered set. Especially when working with large amounts of data, >>>>>>>>> presorting can save a lot of time and battery life. If a bridgeable >>>>>>>>> ordered set was part of the standard library we could use a ordered >>>>>>>>> set in swift without having to use the NSOrderedSet from objective c. >>>>>>>>> Which would be pretty nice in my opinion. Even when using a >>>>>>>>> NSOrderedSet we couldn’t have a generic version of it. >>>>>>>>> >>>>>>>>> 2. A shared datamodel between App and Server. One main advantage of >>>>>>>>> having web servers written in Swift is that we can share code between >>>>>>>>> the server and the app. For servers performance does matter a lot, >>>>>>>>> since they are usually working with much more data than apps. >>>>>>>>> Databases are represented as sets and fetching sorted data from the >>>>>>>>> database can be represented as an ordered set. However, since we >>>>>>>>> don’t have ordered sets we have to choose either a normal set or an >>>>>>>>> array. Sets don’t have an order and arrays can contain the same >>>>>>>>> object multiple times, which makes them both a less suitable choice. >>>>>>>>> >>>>>>>>> 3. Swift has the potential to be used for education. There is a lot >>>>>>>>> of support, for example the playground app on iPad. When it comes to >>>>>>>>> the theory behind data structures and algorithms or to the theory of >>>>>>>>> computation a defined order plays an important role. >>>>>>>>> >>>>>>>>> The biggest issue is that we always have to copy data from a set into >>>>>>>>> an array to have it in a sorted order with losing the safety of >>>>>>>>> uniqueness. Which is not suitable for a safe and performance oriented >>>>>>>>> programming language at all. >>>>>>>>> >>>>>>>>> Last but not least, it fits in the goals of Swift 4 stage 2 and an >>>>>>>>> ordered set can be found in other popular programming languages, too. >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Maik >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> swift-evolution mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
