> ```
> 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?
maybe `sizeOf(value _: T) -> Int` ?
···
On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <fs.output@gmail.com> wrote:
2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org>:On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution < >> swift-evolution@swift.org> wrote:
> On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution < >>> swift-evolution@swift.org> 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?
> --
> -DaveI 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution