> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
