Add wrappers for allocWithTailElems_{n} routines

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?

Thanks.
Alexey Komnin.

Feel free to design and propose these interfaces (in phase 2 of course).

···

on Tue Dec 13 2016, Alexey Komnin <swift-evolution@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?

--
-Dave

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…

- Karl

···

On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Dec 13 2016, Alexey Komnin <swift-evolution@swift.org <mailto:swift-evolution@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).

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Underscored APIs are not guaranteed to exist in the future. The underscoring is a hack because we aren't able to use our normal access control mechanisms with the standard library yet for technical reasons.

-Joe

···

On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Dec 13 2016, Alexey Komnin <swift-evolution@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).

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

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”.

- Dave Sweeris

···

On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Tue Dec 13 2016, Alexey Komnin <swift-evolution@swift.org <mailto:swift-evolution@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…

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!

···

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@swift.org> wrote:

On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > >>> wrote:
on Tue Dec 13 2016, Alexey Komnin <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> wrote:

--
-Dave