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