Oh, one more thing (about this specific change): If we do this, we should add
an “offset” parameter to UnsafeMutableBufferPointer.[move]initialize/assign
(with a default of 0 for source compatibility). Otherwise, it becomes awkward
to initialise a region of a buffer from another buffer.
What I want to write:
buffer.suffix(from: filled).initialize(from: newData)
If SubSequence is not another unsafe pointer, I’d have to do this:
buffer.baseAddress!.advanced(by: filled).initialize(from: newData) // Warning:
deprecated in Swift 4.0
So instead, we should have the ability to write this:
buffer.initialize(startingAt: filled, from: newData) // awkward labels, but src
compat...
But yeah, this post just reminded me that there are a number of small
consistency tweaks we could make to the unsafe-buffer API.
- Karl
> On 24 Mar 2017, at 03:22, Karl Wagner <karl.sw...@springsup.com> wrote:
>
> The convenience initialiser should exist on all of the unsafe buffers, not
> just the raw (untyped) ones.
>
> I’ve run in to this problem a few times, and I think it would get worse if we
> adopted a ContiguouslyStored protocol to formalise accessing the raw-pointers
> of generic collections. It would mean that you couldn’t write code that works
> with UnsafeRawBufferPointer/Data/DispatchData generically, or with
> UnsafeBufferPointer<T>/Array<T>.
>
> Also, there seem to be some implicit conversions for the unsafe-pointer
> types, but UMBP -> UBP requires an awkward initialiser. We should introduce
> an implicit conversion for that case or add an “immutable” computed property
> to UMBP.
>
> And while we’re on the subject, memory allocation/deallocation functions are
> weirdly dispersed. In order to allocate an UnsafeMutableBufferPointer<T>, for
> instance, you have to do:
>
> var buffer: UnsafeMutableBufferPointer<T>
> init(length: Int) {
> let b = UnsafeMutablePointer<T>.allocate(capacity: length)
> buffer = UnsafeMutableBufferPointer(start: b, count: length)
> }
>
> Also, the deallocate API feels weird - since it deallocates n items from the
> head of the pointer, it is a consuming operation and I feel like it should
> return a new pointer (with @discardableResult). Once you’ve deallocated a
> memory address, you can never re-allocate that specific location so there is
> no reason to know about it any more.
>
> - Karl
>
>> On 21 Mar 2017, at 03:21, Andrew Trick via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> This proposal amends SE-0138: Normalize UnsafeRawBufferPointer Slices
>> to fix a design bug: https://github.com/apple/swift-evolution/pull/651
>> <https://github.com/apple/swift-evolution/pull/651>
>>
>> The issue was discussed on swift-evolution in Nov/Dec:
>> See [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029108.html
>>
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029108.html>
>>
>> The implementation of this fix is in PR #8222:
>> https://github.com/apple/swift/pull/8222
>>
>> Fix: Change Unsafe[Mutable]RawBufferPointer's SubSequence type
>>
>> Original: Unsafe[Mutable]RawBufferPointer.SubSequence =
>> Unsafe[Mutable]RawBufferPointer
>>
>> Fixed: Unsafe[Mutable]RawBufferPointer.SubSequence =
>> [Mutable]RandomAccessSlice<Unsafe[Mutable]RawBufferPointer>
>>
>> This is a source breaking bug fix that only applies to
>> post-3.0.1. It's extremely unlikely that any Swift 3 code would rely
>> on the SubSequence type beyond the simple use case of passing a
>> raw buffer subrange to an another raw buffer argument:
>>
>> `takesRawBuffer(buffer[i..<j])`
>>
>> A diagnostic message now instructs users to convert the slice to a
>> buffer using a `rebasing` initializer:
>>
>> `takesRawBuffer(UnsafeRawBufferPointer(rebasing: buffer[i..<j]))`
>>
>> To support this, the following `rebasing` initializers are added:
>>
>> extension UnsafeRawBufferPointer {
>> public init(rebasing slice: RandomAccessSlice<UnsafeRawBufferPointer>)
>> public init(
>> rebasing slice: MutableRandomAccessSlice<UnsafeMutableRawBufferPointer>
>> )
>> }
>>
>> extension UnsafeMutableRawBufferPointer {
>> public init(
>> rebasing slice: MutableRandomAccessSlice<UnsafeMutableRawBufferPointer>
>> )
>> }
>>
>> The source compatibility test builds are unnaffected by this change.
>>
>> -Andy
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
