The guard keyword behaves like a non-crashing assertion that promotes code readability with a compile-time required early exit. “Don’t bother executing past this point if these conditions are not met” is fundamentally different from “if these conditions are met create a new local scope and then continue executing”.
> Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.
And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.
> Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.
And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.