[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Pyry Jahkola 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160604/0244a8ac/attachment.html>

More information about the swift-evolution mailing list