[discarded] Add an eternal lifetime

[stebalien]

Edit: – A better solution would be a more restrictive version of the Copy trait and a new derive attribute. so this can safely be postponed until someone actually needs it.

#Summary Add a lifetime 'eternal such that 'eternal strictly strictly outlives 'static. Structures with an 'eternal lifetime may outlive the program itself.

#Motivation This should make it possible to safely safely send/share 'eternal structured data structures between rust processes (that agree on the layout of the structure) without serialization or unsafe code (no transmuting to/from bytes). My primary use-case is implementing efficient applications with independent failure domains (independent address spaces).

Additionally, this could be used to implement shared buffers (i.e. data structures that live outside of the address space).

#Rough Design A type would have an eternal lifetime if all of its component types have an eternal lifetimes. All types that refer to the current process’s memory (references and pointers) would be bounded by the 'static lifetime (I don’t even know if this concept is expressible in rust as-is).

Data with eternal lifetimes implementing Send would be sendable between processes.

#Drawbacks/Alternatives/Unresolved

Should we just stick to the serialization?

What about sending data structures across the network? Should we break eternal into eternal and host (eternal data structures can be sent across the network, host data structures can only be shared between processes)?

#Before 1.0 If we ever want to even consider doing something like this, the 'eternal lifetime should be reserved.

[vks]

Have you looked at Cap’n Proto? It’s in-memory representation is at the same time the serialized data.

[stebalien]

I was looking for some generic way of checking if a structure can safely be copied between processes/hosts (for use with, for example, inter-process channels). However, I’ve realized that what I want is basically a more restricted version of the Copy trait so a better solution would be an unsafe trait and a new derive attribute (which could easily be added post 1.0 if anyone actually wants this functionality).