On Tue, Sep 5, 2017 at 17:16 Taylor Swift <[email protected]> wrote:
> I’m fine with most of this > > On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick <[email protected]> wrote: > >> >> On Sep 5, 2017, at 9:53 AM, Taylor Swift <[email protected]> wrote: >> >> we agreed to deprecate the strided at:? Note that >> UnsafeMutableRawBufferPointer would still need a byteOffset: argument. >> I’m also still not comfortable with duplicating functionality for the sake >> of having two names >> >> >> I’ll summarize what I think happened in this thread... >> >> I don't think the suggested copyBytes rename was controversial: >> >> UMRP (raw pointer): >> --- copyBytes(from:count) >> +++ copyMemory(from:bytes:) >> >> >> UMRBP (raw buffer): >> --- copyBytes(from:) >> +++ copyMemory(atByteOffset:from:) >> >> --- copyBytes<C>(from:) >> +++ copyMemory(from:) >> >> > no problem with this > > >> >> In the new raw initializeMemory methods, Xiaodi and I agreed to make >> it more clear that the offset is in terms of `self` rather than >> `from`, and to further reduce ambiguity by forcing manual stride >> computation and using an explicit "offset" label. The call site will >> be just as explicit as dropping down to `baseAddress` but without any >> pointer conversion boilerplate. >> >> UMRBP (raw buffer): >> +++ func initializeMemory<T>(atByteOffset:as:from:) >> +++ func moveInitializeMemory<T>(atByteOffset:as:from:) >> >> > Agree, but the label should just be `atByte:`, not `atByteOffset:`. after > all, we don’t use `atOffset:` in the strided case; its obvious that it’s > an offset > The existing APIs use the terminology "byte offset"--for example, URP.load(fromByteOffset:as:). The rationale is that "at" without a noun that follows implies, per Swift API naming guidelines, "at index." If you want to specify, as we do here, what the index _is_, then it's written out in full. > >> >> Than, in the one existing initializeMemory method, just drop the strided >> index. >> It's never used, we want to be consistent in using a byte offset >> for the raw index, and that can be expressed just as easily as pointer >> arithmetic: >> >> UMRP (raw pointer): >> --- func initializeMemory<T>(as:T.Type, at:Int = 0, count:Int = 1, to:T) >> +++ func initializeMemory<T>(as:T.Type, repeating:T, count:Int = 1) >> >> Then you can simply leave these methods as-is: >> > func initializeMemory<T>(as:T.Type, from:UnsafePointer<T>, count:Int) >> > func moveInitializeMemory<T>(as:T.Type, from:UnsafeMutablePointer<T>, >> count:Int) >> >> > yes > > >> We don't have a consensus, but I think the suggestion to distinguish >> between single value vs. multiple semantics was good. Otherwise, >> adding the default count could be very misleading. Normally, we try to >> minimize surface area, but adding two methods for the single-value case >> avoids ambiguity between the buffer and pointer semantics: >> >> UMP (pointer) >> --- func initialize(to:count:(=1)) >> +++ func initialize(to:) >> +++ func initialize(repeating:count:) // no default count >> +++ func assign(to:) >> +++ func assign(repeating:count:) // no default count >> >> UMRP (raw pointer): >> --- func initializeMemory<T>(as:at:(=0)count:(1)to:) >> +++ func initializeMemory<T>(as:repeating:count:) // remove default count >> > > still extremely suspicious of this but i’m willing to compromise. also > there should be an `initializeMemory<T>(at:to:)` to match the typed > methods > Do you mean initializeMemory<T>(as:to:)? > > >> >> -Andy >> >> On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick <[email protected]> wrote: >> >>> I think we’ve agreed to a few minor updates to this proposal. Since >>> there hasn’t been any other feedback on the thread it may be worth posting >>> an amended proposal so we all know what we’ve agreed on. >>> >>> -Andy >>> >>> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> On Sep 3, 2017, at 8:05 PM, Xiaodi Wu <[email protected]> wrote: >>> >>> If we use byte offset, then the at parameter in UnsafeMutableRawPointer >>> should >>>> be removed, since pointer arithmetic can be used instead (just like with >>>> UnsafeMutablePointer). >>>> >>> >>> I agree that it seems quite sensible to remove the ‘at’ parameter >>> altogether from the UMRP method. >>> >>> >>> No code in tree or on github is using the `at` argument. I think it can >>> be removed. A fixit should still be possible. >>> >>> Not convinced moving the at: argument to come before the as: argument >>>> is worth it in terms of source breakage. >>>> >>> >>> Since much of this proposal involves shuffling and relabeling arguments, >>> I’d argue it’s better to break slight more source in one go for the optimal >>> API than to break slightly less for a slightly less optimal API, no? (This >>> is assuming there is agreement that ‘at:as:’ is less prone to >>> misinterpretation than ‘as:at:’.) >>> >>> >>> To be clear, we’re just talking >>> about UnsafeMutableRawBufferPointer.initializeMemory now, so this is purely >>> additive. >>> I think the label needs to be `atByteOffset`, and placing it before `as` >>> makes a lot of sense because it no longer depends on the type’s stride. >>> >>> -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
