On Fri, Aug 5, 2016 at 2:46 AM, rintaro ishizaki <[email protected]> wrote:
> > > 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 > As I mentioned above, it's not only possible but already used in the standard library. For instance, `first` and `first(where:)` for Collection types. > 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
