Ambiguous pointers

[eggrobin]

Low-priority thoughts on alternatives to the polysemic T*.

As discussed, C-style pointers T* (and C++ references T&) have many possible meanings which are not explicit. Moreover, cdecl code forces us to occasionally use C-style pointers as they would be used in C (including for ownership and ownership transfer, optional parameters, etc.), so assigning a single (non-owning) semantic to C-style pointers is bound to fail.

Some current uses of C-style pointers, with replacement proposals:

Parameters

• T const* const arguments for optional parameters.

  Should be replaced with std::optional<T> whenever that becomes a thing.

• T* const arguments for in out parameters.

  • T&:

  The usual (non-Google-styleguide-compliant) approach for modifiable parameters is to use references but that removes the marker (&actual_parameter) at the call site that the styleguide provides (compare with the C# ref actual_parameter, mandatory at the call site, or the GREEN (Steelman) formal_parameter :=: actual_parameter, mandatory if the parameter is named). Moreover, neither approach provides a distinction between in out and out parameters (compare with the C# out actual_parameter, or the GREEN formal_parameter =: actual_parameter).

  • Reference wrapper

  A version of std::reference_wrapper with an explicit constructor (and the associated equivalent of std::ref), which would enforce the call-site marker, could work, but since it uses implicit conversion it impedes template deduction in the body of the callee.

  • Smart pointer

  A non-owning, non-copyable, non-movable, not null smart pointer constructed from a reference at the call site, but with pointer syntax for dereferencing would work (with the inconvenient of pointer syntax in the body of the callee, but we already have that).

• T* const arguments for out parameters.

  Additional restrictions could be placed on the reference wrapper or smart pointer. Here template deduction is not an issue since this should not be convertible to a readable object.

  Non-owning pointers

• A copyable, non-owning "smart" pointer would be useful to explicitly indicate lack of ownership or ownership transfer (such a pointer was proposed but has not made it into the standard).
• A non-owning, not null smart pointer would also be useful (references do that, but do not have pointer syntax).

[eggrobin]

Non-null pointers have been addressed by #241.