on Tue Dec 13 2016, David Sweeris <davesweeris-AT-mac.com> wrote: >> On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution >> <[email protected]> wrote: >> >> >>> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution >>> <[email protected] <mailto:[email protected]>> > >>> wrote: >>> >>> >>> on Tue Dec 13 2016, Alexey Komnin <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Hi everyone! >>>> >>>> I really don't know whether you have discussed it before. So, here is the >>>> deal. >>>> >>>> Currently, Builtin routines like allocWithTailElems_{n} not available >>>> outside of stdlib. On the other hand, those routines are widely used >>>> in implementation of containers: Array, Set, Dictionary and others. >>>> >>>> On the other hand, some Builtin routines are wrapped by publicly >>>> available operators and functions like unsafeBitCast, (==). >>>> ManagedBuffer.create(minimumCapacity:) class method is just a wrapper >>>> around call to allocWithTailElems_1 builtin function. So, it is >>>> possible to implement some containers, like Deque or linked-list using >>>> ManagedBuffer, but it's not enough if developer is going to implement >>>> advanced data structures like OrderedSet, LRU-cache or something more >>>> complex. >>>> >>>> Instead, the developers are forced to use complex pointer arithmetic >>>> with UnsafeRawPtr. My point is: I think the language must provide all >>>> the available tools to build algorithms and data structures. First of >>>> all, it should provide the tools used for stdlib implementation. >>>> >>>> Could we make some ManagedBuffer-alike wrappers around >>>> allocWithTailElems_{n} routines? >>> >>> Feel free to design and propose these interfaces (in phase 2 of course). >> >> Would the optimiser hints also possibly be up for making public >> (_onFastPath() and so)? >> >> You can use them anyway; I don’t know why they’re underscored… > > I believe the underscored stuff is consider an implementation detail > that should be private, but can’t be for some technical reason, and is > subject to change without notice. I think.
Correct. > Now that I’ve said that, someone’s going to go do an analysis of all > the “_*” symbols and point out that 95% of them haven’t changed since > the first Mac OS X Public Beta back in 2000. Then someone else will > say that “subject to” doesn’t mean “will”. Goes without saying, now! -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
