Design discussions for Babel structs

This page is meant to be a repository of design questions and our current best thinking on the answers. At the time of its initial creation, the questions and their answers are relatively fluid. As time progresses, the hope is that the design will stabilize.

Here, I list my opinions in the third person, and I would encourage other contributors to do likewise. By writing this way, we make it clear to everyone who agrees and disagrees with each issue.

1. What does "in" mean for a struct parameter?

There are three main possible IOR signatures for an "in" struct parameter "struct a_Foo a", "struct a_Foo *a", and "const struct a_Foo *a". The first option (pass-by-value) matches the natural meaning on "in" best, but it forces a deep copy of the struct (bad for performance).

The second option, "struct a_Foo *a", is the most flexible. It doesn't require a copy; however, if the impl modifies the contents of the struct, those changes are seen by the caller. This causes in-process calls to behave differently than remote calls.

The third option, "const struct a_Foo *a", prevents changes to the struct itself.

Right now, Tom Epperly likes option 3 the best, option 2 second, and option 1 least. One reason I prefer option 3 is to make "in" different from my preference for "inout" below.

Nanbor agrees with Tom in that option 3 is the best choice although for languages that don't support "const', option 2 would be the way to go.

In the case of RMI, the struct values are only passed from caller to callee.

2. What does "inout" mean for a struct parameter?

There are two main possible IOR signatures for an "inout" struct parameter "struct a_Foo *a" and "struct a_Foo **a". Right now, Tom Epperly favors the first option. The second option implies that the impl can free (the C library call) the struct, malloc a new one, and return it. This leads down the path to reference counting and structs having vtables, and I believe we're trying to avoid that.

Option 1, "struct a_Foo *a" means that the impl sees all the incoming values, and is free to change them. The impl is not allowed to free the incoming pointer.

In the case of RMI, the incoming values are shipped from caller to callee, and on return the outgoing values are shipped from the callee to the caller.

3. What does "out" mean for a struct parameter?

This has the same two options as "inout", "struct a_Foo *a" and "struct a_Foo **a".

Tom Epperly favors option 1 for the same reasons as question 2.

Nanbor thinks option 2 makes more sense for out parameters since one can potentially use an empty pointer to receive an out struct.

In the case of RMI, no incoming struct values are shipped from caller to callee, and on return the outgoing values are shipped from the callee to the caller.

4. What are the reference counting implications for structs that contain object and array references?

I think the simplest rule is say that the reference counting ownerships are the same as if the object/array reference were passed individually with the same mode.

If a.Foo is defined as follows: In the case of "in a.Foo a", the impl has a borrow reference to the sidl.BaseClass, and it is not allowed to have a negative impact on the reference count.

In the case of "inout a.Foo a", the impl owns the incoming reference. It's allowed to deleteRef a.bc and set it to another valid object reference (including NULL). Upon exit, the reference a.bc is returned to the caller who becomes the owner of the reference.

In the case of "out a.Foo a", the impl should overwrite the incoming reference with a valid object reference (including NULL). Upon exit, the reference a.bc is returned to the caller who becomes the owner of the reference.

5. How are structs returned?

Normally, return values are just like "out" parameters. However, there is trouble with that because some of the "out" definitions assume that the caller has provided space for the out value. Should the IOR function return "struct a_Foo" or "struct a_Foo *". The first option requires a copy and may be difficult to do with Fortran, and the second option gets into reference counting.