> On Aug 8, 2017, at 5:49 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick <atr...@apple.com 
> <mailto:atr...@apple.com>> wrote:
> 
>> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is 
>> ready for community review, and I encourage everyone to look it over and 
>> provide feedback. Thank you!
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md>>
> 
> 
> Excellent. Thanks for patiently iterating on this. I know it's time consuming.
> 
> > add a default value of 1 to all size parameters on
> > UnsafeMutablePointer and applicable size parameters on
> > UnsafeMutableRawPointer
> 
> I'm generally ok with this if you have seen the benefit of it in real
> code. However, I do not think any `repeating:` methods should have a
> default count.
> 
> Actually, i believe initialize(to:count:) is currently the one method that 
> already has a default count. That’s probably because the standard library 
> calls this method with a count argument of 1 more than any other memorystate 
> method. I don’t know if this decision was only made for the sake of the 
> stdlib or if it had an API justification.

Right you are. I had just noticed that none of the other `repeating` APIs had a 
default. But if this default argument simplifies real code patterns then I’m 
fine with it.

> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
> 
> Well, I think it's somewhat ridiculous for users to write this every time 
> they allocate a buffer:
> 
> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
> MemoryLayout<UInt>.alignment)`
> 
> If anyone reading the code is unsure about the Swift API's alignment
> guarantee, it's trivial to check the API docs.
> 
> You could introduce a clearly documented default `alignedTo`
> argument. The reason I didn't do that is that the runtime won't
> respect it anyway. But I think it would be fair to go ahead with the
> API and file a bug against the runtime.
> 
> Default argument of MemoryLayout<Int>.alignment is the way to go but as you 
> said i don’t know if that is actually allowed/works. An alternative is to 
> have two allocate methods each, one that takes an alignment argument and one 
> that doesn’t (and aligns to pointer alignment) but that feels inelegant. 
> Default arguments would be better.

Default argument makes sense to me too. Then the raw buffer pointer and regular 
raw pointer APIs can be consistent with each other.

Runtime bug: https://bugs.swift.org/browse/SR-5664

> > and initializeMemory<Element>(as:at:repeating:count:),
> > initializeMemory<Element>(as:from:count:)
> > moveInitializeMemory<Element>(as:from:count:), and
> > bindMemory<Element>(to:count:) to UnsafeMutableRawBufferPointer
> 
> I think you should move the raw pointer changes to a separate bullet point.
> 
> Presumably the raw buffer capacity must match or exceed count * stride?
> 
> -Andy
> 
> The reason the raw buffer pointers don’t fill in their own size is the 
> destination type might not line up with the raw buffer size, and then there’s 
> questions of rounding and whatnot. bindMemory(to:count:) would also have to 
> perform integer division or some other defined behavior. Though if people 
> think computing the strided count inside the buffer pointer method is the 
> right way to go, I’m open to that.

No, I think your API is fine. I just wanted to clarify that we will trap if the 
raw buffer is too small to fit the requested elements.

-Andy

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to