This is all valuable feedback. I also have a bunch of convenience APIs in mind but haven't been pushing them yet because:
- the Swift 4 schedule is tight - I don't want to speculatively add API surface until enough users have had experience with the feature. Maybe there are better ideas. … > On Mar 23, 2017, at 7:22 PM, Karl Wagner <[email protected]> wrote: > > The convenience initialiser should exist on all of the unsafe buffers, not > just the raw (untyped) ones. I think it's fair to add the UnsafeBuffer.init(rebasing:) initializer as part of this SE-0138 amendment. It's not so much a new API as a consistency fix. I’ll update the current proposal. > 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. UnsafeBufferPointer should have init from mutable. We already had a bug for that. Thanks for reminding me: https://bugs.swift.org/browse/SR-3929 I think that needs a new proposal, but it's a trivial addition. I can work on that. I agree that implicit conversions would be nice but does merit some discussion and involves a bit of type system work. You have to be a bit careful with implicit conversion because of potentially ambigous overloads. Implicit conversion is primarily for C interop. Eventually I do think it would be nice to optionally import some pointer+length arguments as UnsafeBuffer. We just don't do it now. Regardless of interop, this would also be handy way to pass an inout argument as a buffer without wrapping it in a closure. Your specific concern seems to be about the mutable -> immutable conversion being implicit though. But that just comes down to writing out the type name. As bad as the type name is, to me that's not worth an evolution proposal at the moment. I suggest filing a bug for any implicit conversion issues, or `immutable` property suggestions for now. > 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) > } We've had a bug open on this since introducing raw buffers: https://bugs.swift.org/browse/SR-3088 This is obvious enough that I can probably sneak it into Swift 4 if I just get around to writing the proposal. > 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. Now we're outside UnsafeBufferPointer territory. UnsafePointer.deallocate(capacity:) needs to be passed the same capacity as allocate. If that's confusing, please file a documentation bug. Or you may be referring to UnsafePointer.deinitialize(count:). That returns a raw pointer to the same memory address to indicate that you can now initialize the same memory as a different type. With move-only types, I think we'll be able to revisit some of the pointer initialize/deinitialize API to be more robust. -Andy > > - Karl > >> On 21 Mar 2017, at 03:21, Andrew Trick via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
