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