[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue
pyry.jahkola at iki.fi
Sat Jun 4 12:19:42 CDT 2016
> On 04 Jun 2016, Erica Sadun wrote:
> Discussion has more or less drawn down. Are there any further significant requests / issues that need addressing? Both standalone functions (my recommended approach) and the MemoryLayout<T> struct approach (alternative, with reasons why I think it's not as ideal) are discussed in-proposal.
> Pull Request: https://github.com/apple/swift-evolution/pull/350
Good proposal, Erica!
Regardless of the little input I've given to this discussion, I actually prefer the set of `memory*` prefixed top-level functions to a `MemoryLayout` struct or tuple.
However, I think it's most common to call these functions with a type argument, and we should thus stick to the practice of keeping that use case short, and the call-with-value case explicit. In particular, I'd avoid the label for a type argument, and say `ofValue:` when passing a value:
memorySize(ofType:) → memorySize(_:)
memorySize(of:) → memorySize(ofValue:)
memoryInterval(ofType:) → memoryInterval(_:)
memoryInterval(of:) → memoryInterval(ofValue:)
memoryAlignment(ofType:) → memoryAlignment(_:)
memoryAlignment(of:) → memoryAlignment(ofValue:)
Secondly, (this might be over-engineering but) would it still make sense to use `@autoclosure` in the `ofValue:` functions because they don't really need their arguments evaluated?
public func memorySize<T>(ofValue _: @autoclosure T -> ()) -> Int
public func memoryInterval<T>(ofValue _: @autoclosure T -> ()) -> Int
public func memoryAlignment<T>(ofValue _: @autoclosure T -> ()) -> Int
— Pyry, whose name gets autocoerced in various ways apparently.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution