Dear Gavin, In the proposal linked as part the P.S., that's actually one of the names listed. It was also recommended by another person outside this list, so I will keep that in mind going forward (the pair of names was `c_out_ptr` and `c_inout_ptr`)! This library is not explicitly an annotation, but it also doubles as that by its design: the free function makes it very noticeable that this parameter is an output parameter. Sincerely, JeanHeyd On Tue, Jul 3, 2018 at 12:15 AM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 3/07/2018 14:42, ThePhD wrote:
This does not have any other use case than C and COM-Style API interoperability: both `out_ptr` and `inout_ptr` and streamlined interfaces purely for this purpose and to make writing against such APIs more pleasant, more performant, and (most of all) more developer-time scale-able than alternative approaches such as wrapping all such initialization-style functions in C++-isms.
Purely for bikeshedding purposes a name like c_out_ptr might be better in that case.
When initially seeing "out_ptr" and the syntax in your original email, at first glance it looked like the intent was as a reference wrapper annotation (to make it more obvious at the call site that the pointer will be modified on return), rather than the typical "solution" of using an /*out*/ comment or similar non-functional and non-checked annotation.
(I suppose you can use std::ref for that purpose, but the intent is less clear. And perhaps less necessary once compilers and libraries start using multiple return values via structured binding.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost