Does protocol support add to an object's size?


(Daryle Walker) #1

I don't know how protocol support works. I asking because I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.

···

Sent from my iPhone


(Slava Pestov) #2

Values of concrete type always have the same size regardless of what protocols the type conforms to.

Slava

···

On Feb 15, 2017, at 9:51 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

I don't know how protocol support works. I asking because I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.

Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #3

The stride of an Array<T> is the width of a pointer, since Arrays are stored indirectly. Also, the allocated capacity may be greater than the number of elements actually contained in the Array. If you want a fixed-size group of elements, with a stride equal to the number of elements multiplied by the per-element stride, use a tuple.

- Karl

···

On 15 Feb 2017, at 18:51, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

I don't know how protocol support works. I asking because I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.

Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #4

Short answer; no.

A protocol can't add stored properties, which are what determine the size/stride of a type; all they can add are computed properties and methods, neither of which are actually stored alongside the objects themselves.

Basically a type's size is memory required to store only the parts that are unique to that specific object (stored properties), all a protocol does is tell the compiler some operations you can perform, the actual code for which is stored elsewhere.

As Karl points out though the type's size isn't necessarily the full picture, as a store property can be a pointer to some other piece of memory such as an object (class, rather than struct) or to an unmanaged buffer and other constructs that are particularly useful for things like arrays.

Also, for future reference, questions like this are more appropriate to the swift-users mailing list; swift-evolution is intended more for language improvements, rather than general queries. Easy enough mistake to make though!

···

On 15 Feb 2017, at 17:51, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

I don't know how protocol support works. I asking because I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.


(Daryle Walker) #5

Values of concrete type always have the same size regardless of what protocols the type conforms to.

So, two struct types with the same instance-level stored properties, but one with no protocol conformance and the other with at least one, have the same stride-of? Does that mean that the latter type keeps no per-instance space for protocol support? Or that all struct types keep protocol accounting information, even when a struct’s protocol list is empty (like the former type)?

···

On Feb 15, 2017, at 3:36 PM, Slava Pestov <spestov@apple.com> wrote:

On Feb 15, 2017, at 9:51 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

I don't know how protocol support works. I asking because I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.


Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com


(Joe Groff) #6

Protocol conformances are a distinct runtime object from the type itself. There's never any direct record of the conformance in a type's own metadata or instances. This is what allows conformances to be added externally by extensions from other modules.

-Joe

···

On Mar 31, 2017, at 9:33 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 3:36 PM, Slava Pestov <spestov@apple.com> wrote:

Values of concrete type always have the same size regardless of what protocols the type conforms to.

So, two struct types with the same instance-level stored properties, but one with no protocol conformance and the other with at least one, have the same stride-of? Does that mean that the latter type keeps no per-instance space for protocol support? Or that all struct types keep protocol accounting information, even when a struct’s protocol list is empty (like the former type)?


(Jordan Rose) #7

At the same time, you are not allowed to assume anything about the layout of structs defined in Swift today. If the compiler wanted to insert the name of the type between every member, it would be permitted to. Please do not assume two structs that look "the same" are laid out the same; if you need to care about in-memory layout, define the struct in C.

Jordan

···

On Mar 31, 2017, at 09:39, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 31, 2017, at 9:33 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 3:36 PM, Slava Pestov <spestov@apple.com> wrote:

Values of concrete type always have the same size regardless of what protocols the type conforms to.

So, two struct types with the same instance-level stored properties, but one with no protocol conformance and the other with at least one, have the same stride-of? Does that mean that the latter type keeps no per-instance space for protocol support? Or that all struct types keep protocol accounting information, even when a struct’s protocol list is empty (like the former type)?

Protocol conformances are a distinct runtime object from the type itself. There's never any direct record of the conformance in a type's own metadata or instances. This is what allows conformances to be added externally by extensions from other modules.


(Daryle Walker) #8

Protocol conformances are a distinct runtime object from the type itself. There's never any direct record of the conformance in a type's own metadata or instances. This is what allows conformances to be added externally by extensions from other modules.

At the same time, you are not allowed to assume anything about the layout of structs defined in Swift today. If the compiler wanted to insert the name of the type between every member, it would be permitted to. Please do not assume two structs that look "the same" are laid out the same; if you need to care about in-memory layout, define the struct in C.

As I said in the original post:

I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.

This is for built-in arrays, which we don’t have yet. I want to make sure that enforcing “no padding outside the inner non-array type” won’t affect doing “cool Swift things” with the type. This question is mainly aimed towards Swift compiler implementors.

···

On Apr 3, 2017, at 4:33 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Mar 31, 2017, at 09:39, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:


Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com


(Charlie Monroe) #9

Protocol conformances are a distinct runtime object from the type itself. There's never any direct record of the conformance in a type's own metadata or instances. This is what allows conformances to be added externally by extensions from other modules.

At the same time, you are not allowed to assume anything about the layout of structs defined in Swift today. If the compiler wanted to insert the name of the type between every member, it would be permitted to. Please do not assume two structs that look "the same" are laid out the same; if you need to care about in-memory layout, define the struct in C.

As I said in the original post:

I want to maintain the stride of an array being the total count times the stride of the element, which would complicate nominal arrays if adding protocols to one breaks that.

This is for built-in arrays, which we don’t have yet. I want to make sure that enforcing “no padding outside the inner non-array type” won’t affect doing “cool Swift things” with the type. This question is mainly aimed towards Swift compiler implementors.

I am not an implementor of the compiler, but the structure, once compiled will have the same layout and size during runtime, no matter what protocols it conforms to. Protocols cannot add stored members and the information about conformance is not stored within the structure instance.

Note that compilers of different Swift versions can slightly modify the layout and the size may be different on different devices (if you use pointer-sized members such as Int, UInt or object references). Once the ABI is stable, you can rely on the size more.

If you need to rely on the structure of the struct more, fall back to C as Jordan suggested. C allows you to create packed structs, etc. which Swift currently doesn't.

···

On Apr 4, 2017, at 1:48 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 3, 2017, at 4:33 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Mar 31, 2017, at 09:39, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:


Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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