On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution < [email protected]> wrote:
> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > > > > > > Having seen the effects in the standard library and in other > > code, I'm concerned that we may have made a mistake in removing > > `sizeofValue` et al without providing a replacement. In the standard > > library, we ended up adding an underscored API that allows > > > > MemoryLayout._ofInstance(someExpression).size > > > > Where someExpression is an autoclosure, and thus not evaluated. I > > wanted to bring up the possibility of introducing a replacement as a > > bufix. > > > > I propose that the way to express the above should be: > > > > MemoryLayout.of(type(of: someExpression)).size > > > > implementable as: > > > > extension MemoryLayout { > > @_transparent > > public > > static func of(_: T.Type) -> MemoryLayout<T>.Type { > > return MemoryLayout<T>.self > > } > > } > > > > I think this API would solve the concerns I had about confusability that > > led me to advocate dropping the ability to ask for the size of a value. > > The only way to use it is to pass a type and these two expressions have > > equivalent meaning: > > > > MemoryLayout<Int> > > MemoryLayout.of(Int.self) > > > > It also has the benefit of isolating the autoclosure magic to type(of:). > > > > ,----[ Aside ] > > | A slightly cleaner use site is possible with a larger API change: > > | > > | MemoryLayout(type(of: someExpression)).size > > | > > | Which would involve changing MemoryLayout from an `enum` to > > | a `struct` and adding the following: > > | > > | extension MemoryLayout { > > | public init(_: T.Type) {} > > | > > | public var size: Int { return MemoryLayout.size } > > | public var stride: Int { return MemoryLayout.stride } > > | public var alignment: Int { return MemoryLayout.alignment } > > | } > > | > > | However I am concerned that dropping ".of" at the use site is worth the > > | added API complexity. > > `---- > > > > Thoughts? > > -- > > -Dave > > > I don't think using "of" is a great burden. > Agreed, but I do think "memory layout of type of my value, size" is a mouthful compared to "size of value". Moreover, something doesn't sit right with me that MemoryLayout<T> and MemoryLayout.of(T.self) would be one and the same thing. Could I suggest an alternative? It's conservative in that it mimics the relationships we had before the proposal was implemented and also maintains the simplicity of the caseless enum: ``` extension MemoryLayout { static func size(ofValue _: T) -> Int { return MemoryLayout.size } // etc. } ``` > -- E > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
