isocpp / isocpp/CppCoreGuidelines

F.16: GSL should provide a helper type alias template

Open
#1,997 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
CSS
Stars
45.3k
Forks
5.6k
PR merge metrics
No merged PRs in 30d

Description

F.16’s enforcement section prescribes that an “in” parameter to a function should be passed by copy when its type has a size less than 2*sizeof(void*), and by const reference otherwise.

@hsutter’s new cppfront project (which is an implementation of his C++ Syntax 2 proposal) shows that this rule can be applied programmatically in the current C++ syntax through the use of a clever type alias template, named cpp2::in in that project and defined here.

So, I’d like to propose that the Core Guidelines borrow this idea and specify a helper type alias template just like this as part of the GSL. Having such a definition readily available in the GSL would allow transparent application of this guideline directly in C++ code—even across different projects as long as the GSL spec is uniform and stable—which would be useful in a lot of cases (and particularly when writing generic code).

The utility of such an alias definition actually extends beyond "in" function arguments: it can also be used as a return type (e.g. in the definition of a getter function for accessing a member of unknown size). AFAICT the return case is not explicitly covered by a guideline (but could in the future; though there's a potential conflict with F.49's "Don't return const T" advice). Microsoft’s reference GSL implementation now defines such an alias for internal use as the return type of gsl::not_null’s get() member function, with the name value_or_reference_return_t. The more general name value_access was also suggested in that case by @hsutter, which I also think is very descriptive. For this reason, I don't propose adopting a name like gsl::in, but instead something more along the line of gsl::value_access (although I'd like something shorter given that it might appear multiple times in a function signature—I'm thinking of something like gsl::read, if we can accept the extra syntactic and semantic ambiguity that comes with that name).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the F.16 enforcement section and review the referenced cppfront include/cpp2util.h definition and Microsoft GSL include/gsl/pointers alias. Compare the proposed semantics and naming with F.49 and the linked GSL discussion. Done means the project has resolved whether to specify a uniform helper alias and documented its name, scope, and use.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.