[SUGGESTION] Refined Parameter Passing Semantics Categories

[ItsBinissTime]

Refining Parameter Passing Semantics

Suggestions below attempt to:

• Extend semantic clarity to the forwarding of value category and cv-qualification.
• Extract passing mechanism control, re-focusing the categories on semantics.
• Present a practical option for call-site passing semantics visibility.
• Enable convenient selection between modifying and non-modifying overloads.
• Enhance clarity and consistency.

The forward category obscures semantics

The forward category models pass-by-forwarding-reference, followed by std::forward on last use of the parameter, allowing the compiler to perform overload resolution when passing the parameter on, based on the value category (l-value or r-value) and cv-qualification (const or not) of the argument that was passed in.

But such a forwarding mechanism is ambiguous with regard to whether it takes arguments to conditionally move or to conditionally modify. The move and inout categories are used for fundamentally different purposes, and forward obfuscates which one it's representing in a given instance.

Instead of forward:

Consider using "move?" (conditional move) when the argument will be moved or not, depending on whether or not the argument is an r-value.

Consider using "inout?" (conditional modification) when the argument will be modified or not, depending on whether or not the argument is const (see the suggestion for better naming below).

copy and in_ref are about passing mechanisms, not semantics

Herb's parameter passing paper gives multiple reasons why, when an argument is guaranteed not to be modified, the compiler should be allowed to decide whether to pass by value or reference. Ultimately though, it can't be argued that programmers should be prohibited from deciding themselves. So for forcing pass-by-value, cpp2 now has a copy passing category. And for forcing pass-by-const-reference, it now has in_ref. These undermine the philosophy of organizing the categories around semantics rather than passing mechanism.

Consider, instead, using modifiers to force a given passing mechanism.

foo: (/*in*/   bar: T) // The compiler chooses the passing mechanism. bar is const.
foo: (/*in*/ & bar: T) // Pass by reference. bar remains const.
foo: (/*in*/ = bar: T) // Pass by value. bar becomes a local variable.

Regardless of the passing mechanism used, "in" semantics is honored. Arguments are not modified.

Call-site Visibility

Herb 's parameter passing paper, poses the question of how parameter passing semantics can reasonably be made visible at the call site. Probably the most helpful information to make visible is argument modified and argument moved. While moves have the move keyword, modifications have no such call site indicator. A succinct syntactic solution, which is symmetrical (ie. consistent) between the two cases, may be a better approach.

Consider requiring postfix "+" in order to pass a modifiable l-value for inout or out (treating modifiable l-values as const arguments unless so marked):

swap(a+, b+);    // a and b will be modified.  
c: = mymap+[d];  // mymap may be modified. d is treated as read-only.  

• If one were unaware that map::operator [] may modify the map it's called on, the compiler would make them aware when they tried to use it. To call it, they must explicitly mark the map for modification (mymap+), which then also makes it clear at a glance to the reader.
• Or where overloads are available, this syntax enables convenient selection of modifying overloads (like the move keyword enables selection of moving overloads).
• Assignment operators and constructors unambiguously signal intent to modify their left hand operands (a += b; c: = d;), so no further call-site visual indication is necessary. However, decoration should still be required when assignment operators are invoked as functions rather than used as operators (operator =(e+, f);).

Consider requiring postfix "-" in order to pass a modifiable l-value for move:

a: = b-;                 // b will be moved.  
myvector.push_back(c-);  // c will be moved.  

• Using language syntax for this is already a positive change from a library function, but this approach minimizes syntactic impact at the call site.
• These call site visual indicators are consistent with each other, and together they probably represent the maximum semantic information that can be unobtrusively included at the call site.

Naming

While this is understandably a taboo topic, there are real issues with naming here. In an early talk on parameter passing, Herb mentioned that people often suggest that "out parameters" shouldn't be supported, and his parameter passing paper quotes examples which mistakenly use out for inout use-cases. These issues likely stem from common conceptions of "out parameters" which are at odds with the semantics of this category. The term is decades old and predates any annotation or linting scheme that could prohibit a function from reading an argument.

Mentions of moving objects, above, are paired with mentions of the move category, but mentions of modifying objects can't be similarly paired (resulting in the awkwardly named suggestion, "inout?", above).

If the categories were consistently named for actions to be taken on arguments (like move), an instructor could say something like, "A function may init, mod, move, or just read a given argument. It may mod or move conditionally. And the passing mechanism can be forced for reading." This language is more natural, consistent, expressive, and clear. It seems to better represent "What, not how" parameter passing. And it side-steps issues around historical understandings of "out parameters".

The impact of these suggestions probably can't be measured, but since ease of teaching, learning, and using the language is a primary goal of cpp2, I believe they should be considered.

[gregmarr]

Ultimately though, it can't be argued that programmers should be prohibited from deciding themselves. So for forcing pass-by-value, cpp2 now has a copy passing category. And for forcing pass-by-const-reference, it now has in_ref. These undermine the philosophy of organizing the categories around semantics rather than passing mechanism.

Not really.

The semantic of in is "a const thing that can only be read from".
The semantic of copy is "a local copy that the function can do anything that it wants with".

That choice is not [just] about passing mechanism. One is const inside the function, one is not.

Since the in semantic can be either pass by const reference or pass by value, and programmers shouldn't be prohibited from deciding which it is, the _ref suffix allows the programmer to specify that it's the const reference and not the copy.

Consider using "inout?" (conditional modification) when the argument will be modified or not, depending on whether or not the argument is const.

When would someone use this? If you don't care if the argument is const or not, because you're not going to modify it, then use in. If you need to be able to modify the argument, use inout.

Consider using "move?" (conditional move) when the argument will be moved or not, depending on whether or not the argument is an r-value.

When would this be used other than as a forwarding reference? Are you proposing that as a different spelling of forward?

[ItsBinissTime]

You bring up some important points.

Herb originally called his design "What, not how" parameter passing, and described the categories as "declarations of intent." In this context, the "semantics" of the parameter passing semantics categories is limited to what type of action the function will take on the given argument, and is not about how it will be accomplished (even though, as you point out, "how" can fall under the broader meaning of the word). The semantics he defined are:

• The function will not modify the argument.
• The function may modify the argument.
• The function will assign to the argument, without reading it first.
• The function will move the argument's resources to another owner.

He acknowledged the probable need to provide a working copy of an argument without causing accidental double copies, but yet didn't include the copy category, because it doesn't represent unique semantics in this sense.

The addition of copy and in_ref, as new categories, is a concession to the needs of certain use cases (as forward always was). I'm pointing out it's possible to support these use cases without violating the "What, not how" design (or at least infringing upon it less), by addressing them in an orthogonal manner, with "how" modifiers, rather than by adding "not-really-what" categories—thereby keeping the collection of categories minimal, consistent, and focused.

When would you use [inout?]?

Consider std::map. It has operator[], which may create a new item with the given key if one doesn't exist, and it has at(), which will not. In similar situations, developers may prefer to make modifying and non-modifying overloads with the same name, differentiating by cv-qualification instead (especially given a mechanism like the suggested postfix "+"). And if such an overload set can exist, then a function that forwards arguments to such an overload set can exist.

It could be argued that forwarding cv-qualification isn't an important use case, and we could get by without it (requiring developers to write out the overloads instead). But std::forward—and therefore the forward category—supports it, and my point is its use cases could be supported in a way that specifies—rather than obscures—the semantics of the non-default categories to which arguments may be forwarded.

When would [move?] be used other than as a forwarding reference? Are you proposing that as a different spelling of forward?

If it were decided that only value category forwarding should be supported, I would propose using (a renamed) forward as the default category, so as not to bother the programmer with this semantics decision at all. Treating l-values as read-only, while forwarding value category, seems like ideal default semantics.

In fact, this could be done anyway, to create the most convenient (though less symmetric) version:

• init—The function will assign to the argument, without reading it first.
• mod—The function may modify the argument (no const arguments allowed).
• mod?—The function may modify the argument if it's not const (by forwarding to mod overloads).
• move—The function will move the argument's resources to another owner (no l-value arguments allowed).
• read—[default] The function will not modify l-values but may move r-values (by forwarding to move overloads).

And the passing mechanism modifiers could still be applied to read.