-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[libcxx] renames some template type parameters #76540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -45,6 +45,22 @@ other implementations (e.g. system headers), the test in | |||||
``libcxx/test/libcxx/system_reserved_names.gen.py`` contains the list of | ||||||
reserved names that can't be used. | ||||||
|
||||||
We use the following names to refer to various tempalate type parameters: | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks a lot for adding documentation! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
* ``_Iter``, to refer to an iterator type. Some alterations are used if multiple | ||||||
iterators with different categories appear in the same template: | ||||||
* ``_InIter`` to disambiguate input iterators | ||||||
* ``_ForwardIter`` to disambiguate input iterators | ||||||
* ``_BiIter`` to disambiguate input iterators | ||||||
* ``_RandomIter`` to disambiguate input iterators | ||||||
* ``_ContgiuousIter`` to disambiguate input iterators | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
* ``_OutIter`` to disambiguate output iterators | ||||||
* ``_Sent``, to refer to sentinels | ||||||
* ``_Func``, to refer to arbitrary invocable objects | ||||||
* ``_Pred``, to refer to predicates | ||||||
* ``_Comp``, to refer to comparators | ||||||
* ``_Proj``, to refer to projections | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about adding the common |
||||||
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe add a comment that older code may use other conventions. For example in |
||||||
Unqualified function calls are susceptible to | ||||||
`argument-dependent lookup (ADL) <https://en.cppreference.com/w/cpp/language/adl>`_. | ||||||
This means calling ``move(UserType)`` might not call ``std::move``. Therefore, | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with the change itself, but I question the added value of the documentation. Indeed, this naming scheme works well for e.g. algorithms where the iterators (or predicates, or whatever) don't have any semantics associated to them. However, in other parts of the code, it may convey more information to call the iterator parameter something other than its iterator category. I think it would be better to let people make the right naming decision based on what their code does. However, in cases where we're e.g. writing a new algorithm, folks would end up starting from (or getting inspiration from) code that consistently has the naming we want, so this might end up not being an issue at all.
Basically, I have a slight concern that documenting this naming scheme is going to be too strict, since there are cases where this naming scheme is not what we want. But either way I'm fine with this.
Maybe rewording to
would alleviate my concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 -- the new documentation is great, but IMO should make it clear that these names are used when more specific names are not available, i.e. it's not a 100% requirement to use this naming scheme. I think adding "generally" would pretty much solve this, but I could also suggest adding a note like: