[swift-evolution] [Pitch] Swift needs fixed-size array

Karl Wagner razielim at gmail.com
Mon Apr 17 17:51:33 CDT 2017

> On 18 Apr 2017, at 00:29, Karl Wagner <karl.swift at springsup.com> wrote:
>> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> This is the best approach that I’m aware of. It does bake in an ABI assumption that the tuple layout will be contiguous and strided/addressable. Monitor https://bugs.swift.org/browse/SR-3726 <https://bugs.swift.org/browse/SR-3726> for changes here. Note that you can also a little more “pure” in a sense if you construct an UnsafeBufferPointer from your UnsafeRawPointer and operate on that. Currently, the compiler does not always elide the copy in the getter, see https://bugs.swift.org/browse/SR-4581 <https://bugs.swift.org/browse/SR-4581>
> Will the compiler ever optimise an UBP allocation on to the stack? For example, I’ve written plenty of code such as:
> let ptr = UnsafeRawBufferPointer.allocate(count: 128)
> defer { ptr.deallocate(count: 128) }
> ...when interfacing with C APIs. Which is basically the definition of a stack allocation. That would perhaps be the “swiftier” way to do it; to let the compiler determine how to allocate the memory based on what it knows about its expected lifetime.

I’ll answer that: no, it won’t.

echo "let ptr = UnsafeMutableRawPointer.allocate(bytes: 128, alignedTo: 1); defer { ptr.deallocate(bytes: 128, alignedTo: 1) }" | swiftc -O -emit-assembly -

	.section	__TEXT,__text,regular,pure_instructions
	.macosx_version_min 10, 9
	.globl	_main
	.p2align	4, 0x90
	pushq	%rbp
	movq	%rsp, %rbp
	movl	$128, %edi
	xorl	%esi, %esi
	callq	_swift_rt_swift_slowAlloc   ; a.k.a. ‘malloc'
	movq	%rax, __Tv4main3ptrSv(%rip)
	movl	$128, %esi
	xorl	%edx, %edx
	movq	%rax, %rdi
	callq	_swift_rt_swift_slowDealloc ; a.k.a ‘free'
	xorl	%eax, %eax
	popq	%rbp

Would be cool to do one day, though.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/97c137ba/attachment.html>

More information about the swift-evolution mailing list