MemoryLayout for a value

Evolution Discussion
21

> ```
> 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?
> --
> -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
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

22

> ```
> 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

···

2016-08-05 16:20 GMT+09:00 Xiaodi Wu <xiaodi.wu@gmail.com>:

On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <fs.output@gmail.com> > wrote:

maybe `sizeOf(value _: T) -> Int` ?

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?
> --
> -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
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

23

> Agreed, but I do think "memory layout of type of my value, size" is a
> mouthful compared to "size of value".

It is, but it would avoid confusion.

> Moreover, something doesn't sit right with me that MemoryLayout<T> and
> MemoryLayout.of(T.self) would be one and the same thing.

As far as I'm concerned, that's a feature, not a bug. Unless you can
describe why it should be different, “it doesn't sit right” is not a
helpful argument.

Originally, I'd actually half-way typed out a fuller argument, then deleted
it, assuming most would find it to be uninteresting due to obviousness.
Let's see:

Unless I'm mistaken, every place where one might write `MemoryLayout<T>`
can be replaced with `MemoryLayout.of(T.self)`.

In my proposal, yes.

(Yes, I understand that there are places where substituting in the
other direction would be unsatisfactory, hence this follow-up thread.)
However, I understand it to be a bug, not a feature, to have two
different ways of spelling the same thing, because it necessarily
brings confusion as to why there must be two of them, and I therefore
consider this proposed design to be suboptimal. You titled this
thread "MemoryLayout for a value": I agree that that's what we
need. It ought to be possible to provide facilities for exactly that
*without* also providing an entirely duplicative way of spelling
MemoryLayout for a type.

Fair enough.

> 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.
> }
> ```

That introduces even more potential for confusion than adding forwarding
vars to instances does. Now you're talking about “overloading” a static
property with a static method having the same base name.

IMO, here's where it's a feature, not a bug. I propose `size(ofValue:)` and
`size` because they *are* related, just like how `first(where:)` and
`first` are related for a Collection.

GOod point.

Moreover, the whole thing reads exactly as it should (and, not by
accident, nearly identically to this thread's subject line): "memory
layout size of value x". What is the source of confusion that you
think would arise from this pseudo-overloading, and why are you
emphasizing the fact that both would be static properties/methods (is
it less confusing when it's not static)?

It's less confusing when only one of them is static and the other isn't.

But you've made some excellent points here. Mulling...

···

on Thu Aug 04 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

On Wed, Aug 3, 2016 at 11:32 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Aug 03 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

--
-Dave

24

Xiaodi, not to put you on the spot or anything... but how would you like
to write a proposal and create a pull request for the changes to the
standard library? ;-)

···

on Thu Aug 04 2016, Dave Abrahams <swift-evolution@swift.org> wrote:

on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:

On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org> wrote:

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.
}

I like this API. I think given all the alternatives that we explored,
it is better than those. I also think that it nicely avoids the
following issue with the proposed MemoryLayout.of(type(of:
someExpression)).size syntax.

Imagine that you have a value whose static type differs from the
dynamic type. For example, a protocol existential:

protocol P {}
extension Int : P {}
var x: P = 10

The question is, what does MemoryLayout.of(type(of: x)).size compute,
size of the existential box, or the size of an Int instance? The
semantics of 'type(of:)' are "return the dynamic type", so the
straightforward conclusion is that MemoryLayout.of(type(of: x)).size
returns the size of the dynamic type instance, of Int.

What actually happens is that 'type(of: x)' returns a dynamic value of
'Int.self', statically typed as 'P.Type'. So P gets deduced for the
generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
x)).size returns the size of the protocol box.

I think due to this complex interaction, using type(of:) might lead to
confusing code, and thus I like Xiaodi's approach better.

Dmitri

Okay, I'm convinced; that's what we should do.

--
-Dave

25

> ```
> 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.

···

On Fri, Aug 5, 2016 at 2:46 AM, rintaro ishizaki <fs.output@gmail.com> wrote:

2016-08-05 16:20 GMT+09:00 Xiaodi Wu <xiaodi.wu@gmail.com>:

On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <fs.output@gmail.com> >> wrote:

maybe `sizeOf(value _: T) -> Int` ?

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?
> --
> -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
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

26

>> 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.
>> }
>> ```
>
> I like this API. I think given all the alternatives that we explored,
> it is better than those. I also think that it nicely avoids the
> following issue with the proposed MemoryLayout.of(type(of:
> someExpression)).size syntax.
>
> Imagine that you have a value whose static type differs from the
> dynamic type. For example, a protocol existential:
>
> protocol P {}
> extension Int : P {}
> var x: P = 10
>
> The question is, what does MemoryLayout.of(type(of: x)).size compute,
> size of the existential box, or the size of an Int instance? The
> semantics of 'type(of:)' are "return the dynamic type", so the
> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> returns the size of the dynamic type instance, of Int.
>
> What actually happens is that 'type(of: x)' returns a dynamic value of
> 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> x)).size returns the size of the protocol box.
>
> I think due to this complex interaction, using type(of:) might lead to
> confusing code, and thus I like Xiaodi's approach better.
>
> Dmitri

Okay, I'm convinced; that's what we should do.

Proposal and stdlib PRs have both been created.

···

On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:
> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution > > <swift-evolution@swift.org> wrote:

--
-Dave

27

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout<P>.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout<S1>.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout <S2>.size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

** Confuse:
MemoryLayout <S2.Type>.size
//r3: Int = 0

MemoryLayout <P.Type>.size
//r4: Int = 16

Xiaodi Wu via swift-evolution <swift-evolution@swift.org>于2016年8月5日
周五16:34写道：

···

On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:

> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution >> > <swift-evolution@swift.org> wrote:
>> 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.
>> }
>> ```
>
> I like this API. I think given all the alternatives that we explored,
> it is better than those. I also think that it nicely avoids the
> following issue with the proposed MemoryLayout.of(type(of:
> someExpression)).size syntax.
>
> Imagine that you have a value whose static type differs from the
> dynamic type. For example, a protocol existential:
>
> protocol P {}
> extension Int : P {}
> var x: P = 10
>
> The question is, what does MemoryLayout.of(type(of: x)).size compute,
> size of the existential box, or the size of an Int instance? The
> semantics of 'type(of:)' are "return the dynamic type", so the
> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> returns the size of the dynamic type instance, of Int.
>
> What actually happens is that 'type(of: x)' returns a dynamic value of
> 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> x)).size returns the size of the protocol box.
>
> I think due to this complex interaction, using type(of:) might lead to
> confusing code, and thus I like Xiaodi's approach better.
>
> Dmitri

Okay, I'm convinced; that's what we should do.

Proposal and stdlib PRs have both been created.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

28

Addition:

I think protocol should't has size, or it's size should be zero.
Because you can't put the 40 bytes data in anywhere.

Boris Wang <kona.ming@gmail.com>于2016年8月6日 周六10:35写道：

···

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout<P>.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout<S1>.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout <S2>.size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

** Confuse:
MemoryLayout <S2.Type>.size
//r3: Int = 0

MemoryLayout <P.Type>.size
//r4: Int = 16

Xiaodi Wu via swift-evolution <swift-evolution@swift.org>于2016年8月5日
周五16:34写道：

On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> >> wrote:

on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:

> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution >>> > <swift-evolution@swift.org> wrote:
>> 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.
>> }
>> ```
>
> I like this API. I think given all the alternatives that we explored,
> it is better than those. I also think that it nicely avoids the
> following issue with the proposed MemoryLayout.of(type(of:
> someExpression)).size syntax.
>
> Imagine that you have a value whose static type differs from the
> dynamic type. For example, a protocol existential:
>
> protocol P {}
> extension Int : P {}
> var x: P = 10
>
> The question is, what does MemoryLayout.of(type(of: x)).size compute,
> size of the existential box, or the size of an Int instance? The
> semantics of 'type(of:)' are "return the dynamic type", so the
> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> returns the size of the dynamic type instance, of Int.
>
> What actually happens is that 'type(of: x)' returns a dynamic value of
> 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> x)).size returns the size of the protocol box.
>
> I think due to this complex interaction, using type(of:) might lead to
> confusing code, and thus I like Xiaodi's approach better.
>
> Dmitri

Okay, I'm convinced; that's what we should do.

Proposal and stdlib PRs have both been created.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

29

What’s so confusing about MemoryLayout<T.Type>.size?

size in this context gives you the size for the metatype of T, not the size of T.

If I memorize correctly:

Size of metatypes of value types and functions/closures is 0.
Size for class metatypes is 8.
Size for protocols metatypes (in your case it’s P.Protocol, not P.Type) is 16 except for the (old) empty protocol Any which is 8.
You may ask why these metatypes have these sizes?! I can’t answer this question, because I don’t know the technical reason, but it doesn’t matter in our case.

Furthermore there is a difference between T.Type and what you get from T.self.

T.self returns a concrete metatype for T. T.Type is a metatype supertype for all subtypes of T if there exist a subtype relationship.

That’s why something like this works fine:

let a1: Any.Type = Int.self // `Int.self` is 0 where `Any.self` is 8
let a2: Any.Type = P.self // same story with different sizes
We’re revising our proposal to provide a clear distinction of this behavior and get rid of .Protocol and .Type.

···

--
Adrian Zubarev
Sent with Airmail

Am 6. August 2016 um 04:35:50, Boris Wang via swift-evolution (swift-evolution@swift.org) schrieb:

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout<P>.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout<S1>.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout <S2>.size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

** Confuse:
MemoryLayout <S2.Type>.size
//r3: Int = 0

MemoryLayout <P.Type>.size
//r4: Int = 16

30

The size of a variable of static type S2 is not equal to the size of
the variable of static type P, even though it can dynamically contain
an instance of S2.

Consider:

var x: P = S2(v2: 0, x: 0)

The size of x is not equal to the size of S2.

Dmitri

···

On Fri, Aug 5, 2016 at 7:35 PM, Boris Wang via swift-evolution <swift-evolution@swift.org> wrote:

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout<P>.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout<S1>.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout <S2>.size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

31

Addition:

I think protocol should't has size, or it's size should be zero.
Because you can't put the 40 bytes data in anywhere.

You certainly can. If protocols didn't have a size, Array wouldn't be
able to store them.

···

on Fri Aug 05 2016, Boris Wang <swift-evolution@swift.org> wrote:

Boris Wang <kona.ming@gmail.com>于2016年8月6日 周六10:35写道：

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout<P>.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout<S1>.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout <S2>.size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

** Confuse:
MemoryLayout <S2.Type>.size
//r3: Int = 0

MemoryLayout <P.Type>.size
//r4: Int = 16

Xiaodi Wu via swift-evolution <swift-evolution@swift.org>于2016年8月5日
周五16:34写道：

On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> >>> wrote:

on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:

> On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution >>>> > <swift-evolution@swift.org> wrote:
>> 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.
>> }
>> ```
>
> I like this API. I think given all the alternatives that we explored,
> it is better than those. I also think that it nicely avoids the
> following issue with the proposed MemoryLayout.of(type(of:
> someExpression)).size syntax.
>
> Imagine that you have a value whose static type differs from the
> dynamic type. For example, a protocol existential:
>
> protocol P {}
> extension Int : P {}
> var x: P = 10
>
> The question is, what does MemoryLayout.of(type(of: x)).size compute,
> size of the existential box, or the size of an Int instance? The
> semantics of 'type(of:)' are "return the dynamic type", so the
> straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> returns the size of the dynamic type instance, of Int.
>
> What actually happens is that 'type(of: x)' returns a dynamic value of
> 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
> generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> x)).size returns the size of the protocol box.
>
> I think due to this complex interaction, using type(of:) might lead to
> confusing code, and thus I like Xiaodi's approach better.
>
> Dmitri

Okay, I'm convinced; that's what we should do.

Proposal and stdlib PRs have both been created.

--
-Dave

_______________________________________________
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

--
-Dave

32

Do you means a array of protocol P, rather than a array of element conform
with P?
Dave Abrahams via swift-evolution <swift-evolution@swift.org>于2016年8月6日
周六13:22写道：

···

on Fri Aug 05 2016, Boris Wang <swift-evolution@swift.org> wrote:

> Addition:
>
> I think protocol should't has size, or it's size should be zero.
> Because you can't put the 40 bytes data in anywhere.

You certainly can. If protocols didn't have a size, Array wouldn't be
able to store them.

>
>
> Boris Wang <kona.ming@gmail.com>于2016年8月6日 周六10:35写道：
>
>> codes in swift REPL:
>>
>> protocol P {
>> var x:Int {get}
>> }
>> MemoryLayout<P>.size
>> //r0 : Int = 40
>>
>> struct S1 {
>> var v1:Int = 0
>> }
>> MemoryLayout<S1>.size
>> //r1: Int =8
>>
>> struct S2: P {
>> var v2: Int
>> var x:Int
>> }
>> MemoryLayout <S2>.size
>> //r2: Int = 16
>>
>> ** Question:
>> Why we need to known the size of a object that can't be instanced?
>>
>> ** Confuse:
>> MemoryLayout <S2.Type>.size
>> //r3: Int = 0
>>
>> MemoryLayout <P.Type>.size
>> //r4: Int = 16
>>
>>
>>
>> Xiaodi Wu via swift-evolution <swift-evolution@swift.org>于2016年8月5日
>> 周五16:34写道：
>>
>>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> > >>> wrote:
>>>
>>>>
>>>> on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:
>>>>
>>>> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution > >>>> > <swift-evolution@swift.org> wrote:
>>>> >> 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.
>>>> >> }
>>>> >> ```
>>>> >
>>>> > I like this API. I think given all the alternatives that we
explored,
>>>> > it is better than those. I also think that it nicely avoids the
>>>> > following issue with the proposed MemoryLayout.of(type(of:
>>>> > someExpression)).size syntax.
>>>> >
>>>> > Imagine that you have a value whose static type differs from the
>>>> > dynamic type. For example, a protocol existential:
>>>> >
>>>> > protocol P {}
>>>> > extension Int : P {}
>>>> > var x: P = 10
>>>> >
>>>> > The question is, what does MemoryLayout.of(type(of: x)).size
compute,
>>>> > size of the existential box, or the size of an Int instance? The
>>>> > semantics of 'type(of:)' are "return the dynamic type", so the
>>>> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>>>> > returns the size of the dynamic type instance, of Int.
>>>> >
>>>> > What actually happens is that 'type(of: x)' returns a dynamic value
of
>>>> > 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
>>>> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>>>> > x)).size returns the size of the protocol box.
>>>> >
>>>> > I think due to this complex interaction, using type(of:) might lead
to
>>>> > confusing code, and thus I like Xiaodi's approach better.
>>>> >
>>>> > Dmitri
>>>>
>>>> Okay, I'm convinced; that's what we should do.
>>>>
>>>
>>> Proposal and stdlib PRs have both been created.
>>>
>>>
>>>> --
>>>> -Dave
>>>>
>>> _______________________________________________
>>> 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
>

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

33

I think the underlying issue isn’t that MemoryLayout<T> vs MemoryLayout<T.Type> is confusing, it’s that our metatype system is a little awkward, so the way you construct a MemoryLayout<X> can lead to non-obvious results unless you’re an expert. Given time constraints, the most practical solution which gives us the best product for Swift 3.0 is to revise the MemoryLayout interface, but I think most users would be happy to see some simplification of the metatype system for Swift >3.0.

Personally I only sporadically remember which name means what in a given context. Oh, the dark corners I would have been lost in without code-completion…

···

On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

What’s so confusing about MemoryLayout<T.Type>.size?

size in this context gives you the size for the metatype of T, not the size of T.

If I memorize correctly:

Size of metatypes of value types and functions/closures is 0.
Size for class metatypes is 8.
Size for protocols metatypes (in your case it’s P.Protocol, not P.Type) is 16 except for the (old) empty protocol Any which is 8.
You may ask why these metatypes have these sizes?! I can’t answer this question, because I don’t know the technical reason, but it doesn’t matter in our case.

Furthermore there is a difference between T.Type and what you get from T.self.

T.self returns a concrete metatype for T. T.Type is a metatype supertype for all subtypes of T if there exist a subtype relationship.

That’s why something like this works fine:

let a1: Any.Type = Int.self // `Int.self` is 0 where `Any.self` is 8
let a2: Any.Type = P.self // same story with different sizes
We’re revising our proposal to provide a clear distinction of this behavior and get rid of .Protocol and .Type.

34

Do you means a array of protocol P, rather than a array of element conform
with P?

Yes.

···

on Sat Aug 06 2016, Boris Wang <swift-evolution@swift.org> wrote:

Dave Abrahams via swift-evolution
<swift-evolution@swift.org>于2016年8月6日
周六13:22写道：

on Fri Aug 05 2016, Boris Wang <swift-evolution@swift.org> wrote:

> Addition:
>
> I think protocol should't has size, or it's size should be zero.
> Because you can't put the 40 bytes data in anywhere.

You certainly can. If protocols didn't have a size, Array wouldn't be
able to store them.

>
>
> Boris Wang <kona.ming@gmail.com>于2016年8月6日 周六10:35写道：
>
>> codes in swift REPL:
>>
>> protocol P {
>> var x:Int {get}
>> }
>> MemoryLayout<P>.size
>> //r0 : Int = 40
>>
>> struct S1 {
>> var v1:Int = 0
>> }
>> MemoryLayout<S1>.size
>> //r1: Int =8
>>
>> struct S2: P {
>> var v2: Int
>> var x:Int
>> }
>> MemoryLayout <S2>.size
>> //r2: Int = 16
>>
>> ** Question:
>> Why we need to known the size of a object that can't be instanced?
>>
>> ** Confuse:
>> MemoryLayout <S2.Type>.size
>> //r3: Int = 0
>>
>> MemoryLayout <P.Type>.size
>> //r4: Int = 16
>>
>>
>>
>> Xiaodi Wu via swift-evolution
>> <swift-evolution@swift.org>于2016年
>> 8月5日
>> 周五16:34写道：
>>
>>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams@apple.com> >> >>> wrote:
>>>
>>>>
>>>> on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:
>>>>
>>>> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution >> >>>> > <swift-evolution@swift.org> wrote:
>>>> >> 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.
>>>> >> }
>>>> >> ```
>>>> >
>>>> > I like this API. I think given all the alternatives that we
explored,
>>>> > it is better than those. I also think that it nicely avoids the
>>>> > following issue with the proposed MemoryLayout.of(type(of:
>>>> > someExpression)).size syntax.
>>>> >
>>>> > Imagine that you have a value whose static type differs from the
>>>> > dynamic type. For example, a protocol existential:
>>>> >
>>>> > protocol P {}
>>>> > extension Int : P {}
>>>> > var x: P = 10
>>>> >
>>>> > The question is, what does MemoryLayout.of(type(of: x)).size
compute,
>>>> > size of the existential box, or the size of an Int instance? The
>>>> > semantics of 'type(of:)' are "return the dynamic type", so the
>>>> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>>>> > returns the size of the dynamic type instance, of Int.
>>>> >
>>>> > What actually happens is that 'type(of: x)' returns a dynamic value
of
>>>> > 'Int.self', statically typed as 'P.Type'. So P gets deduced for the
>>>> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>>>> > x)).size returns the size of the protocol box.
>>>> >
>>>> > I think due to this complex interaction, using type(of:) might lead
to
>>>> > confusing code, and thus I like Xiaodi's approach better.
>>>> >
>>>> > Dmitri
>>>>
>>>> Okay, I'm convinced; that's what we should do.
>>>>
>>>
>>> Proposal and stdlib PRs have both been created.
>>>
>>>
>>>> --
>>>> -Dave
>>>>
>>> _______________________________________________
>>> 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
>

--
-Dave

_______________________________________________
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

--
-Dave

35

+1

* I think swift expose too much informations inside compiler to the user。

* I can't imagine, a modern, swift language can't get the size of T/t with
same API:
MemoryLayout<T>.size
MemoryLayout.size(ofValue:t)

Karl via swift-evolution <swift-evolution@swift.org>于2016年8月6日 周六23:23写道：

···

On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

What’s so confusing about MemoryLayout<T.Type>.size?

size in this context gives you the size for the metatype of T, not the
size of T.

If I memorize correctly:

   - Size of metatypes of value types and functions/closures is 0.
   - Size for class metatypes is 8.
   - Size for protocols metatypes (in your case it’s P.Protocol, not
   P.Type) is 16 except for the (old) empty protocol Any which is 8.

You may ask why these metatypes have these sizes?! I can’t answer this
question, because I don’t know the technical reason, but it doesn’t matter
in our case.

Furthermore there is a difference between T.Type and what you get from
T.self.

T.self returns a concrete metatype for T. T.Type is a metatype supertype
for all subtypes of T if there exist a subtype relationship.

That’s why something like this works fine:

let a1: Any.Type = Int.self // `Int.self` is 0 where `Any.self` is 8
let a2: Any.Type = P.self // same story with different sizes

We’re revising our proposal to provide a clear distinction of this
behavior and get rid of .Protocol and .Type.

I think the underlying issue isn’t that MemoryLayout<T> vs
MemoryLayout<T.Type> is confusing, it’s that our metatype system is a
little awkward, so the way you construct a MemoryLayout<X> can lead to
non-obvious results unless you’re an expert. Given time constraints, the
most practical solution which gives us the best product for Swift 3.0 is to
revise the MemoryLayout interface, but I think most users would be happy to
see some simplification of the metatype system for Swift >3.0.

Personally I only sporadically remember which name means what in a given
context. Oh, the dark corners I would have been lost in without
code-completion…

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution