2016-08-05 16:20 GMT+09:00 Xiaodi Wu <[email protected]>: > On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <[email protected]> > wrote: > >> > ``` >> > extension MemoryLayout { >> > static func size(ofValue _: T) -> Int { return MemoryLayout.size } >> > // etc. >> > } >> > ``` >> >> I don't think we can do this while we have: >> >> public static var size: Int { >> > > Why not? >
My bad. Sorry, never mind. I didn't know we can have such overloads (property and func, same basename) :O > > maybe `sizeOf(value _: T) -> Int` ? >> >> >> 2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution < >> [email protected]>: >> >>> 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 >>> >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
