Template for a possible future object model

[dabrahams (Dave Abrahams)]

@filip-sakel

How did you settle on these four parameter-passing conventions? In any language, these conventions are bound to have overlaps, so why was this model chosen? For example, why not just return a tuple with the primary return value and what would otherwise be a set parameter. I guess my questions extends to whether you used a matrix of reading a parameter, consuming it and writing to it (or something to that effect), to come up with your parameter-passing conventions.

We started with a few ideas, like that passing a parameter to a function in the normal way should neither copy nor consume it, and that Swift's inout was probably just about perfect, and tried to see where following those ideas to their conclusions might lead if we wanted to handle move-only types. It wasn't as formal as laying out a matrix. @Alvae writes more about the reasons for the set convention here (but please bring any questions back to this thread). I am not sure that it's a crucial part of the model, but if you look at the Copyable and Sinkable protocols defined above I think it creates a very understandable relationship between intialization and assignment.