[swift-evolution] Add wrappers for allocWithTailElems_{n} routines

[Dave Abrahams]

on Tue Dec 13 2016, David Sweeris <davesweeris-AT-mac.com> wrote:

>> On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>
>>> wrote:
>>> 
>>> 
>>> on Tue Dec 13 2016, Alexey Komnin <swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>> 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