StrictValueType protocol

[tera]

If you want to pitch "HomogenousTuple" (and I'd welcome that as well) - it should be a separate discussion. There's nothing wrong in using, say, "struct S { var x, y, z, t: UInt64 }" as an area capable of holding at least 32 bytes, so strictly speaking HomogenousTuple is not required for "StrictValueType" protocol (and neither is StrictValueArray / StrictValueString – they are just good examples of utilising it).

As an author of the original proposal, which one of these did you mean:

@tera

• POD/PDS values (those can be recreated as "copies" from bits in a different process).
• values that can be recreated as copies from bits in the same process only.
• a value that can be recreated as a unique copy from bits in the same process (original value is destroyed). Attempt to create a second copy from the same bits should fail (somehow), or successfully create a new unique copy with the previously unique copy destroyed the moment the new unique copy is created (Edited).

Or if you meant something totally different please clarify.

[henrikdvn (Henrik Dvergsdal)]

@tera

If you want to pitch "HomogenousTuple" (and I'd welcome that as well) - it should be a separate discussion.

Sorry if I was out of line. HomogenousTuple has already been pitched and is a fairly well defined concept. Please just take my mention as support for this functionality. It is not essential, but it would make it easier to declare robust and efficient stack allocatable storage.

Regarding copy functionality I'll go for the second option (copying within the same process). My primary motivation is related to memory management efficiency. The purpose of StrictValueType is to enable collection types that don't require ARC and can safely be stack allocated inside code blocks.

If the upcoming BitwiseCopyable protocol excludes types with reference counted properties and does not introduce unnecessary complexity, I think it will do the job.