[Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify

[Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

            Bug ID: 101739
           Summary: Some function parameters in <ranges> missing uglify
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hewillk at gmail dot com
  Target Milestone: ---

Hey, Patrick, I found that you uglify some function parameters in yesterday’s
r12-2676 to prevent user-defined macros from polluting names.

There are also some function parameters missing uglifying in <ranges>, it will
be more friendly to users if they are underlined:



--- include/std/ranges
+++ include/std/ranges
@@ -1994,8 +1994,8 @@ namespace views::__adaptor
       take_view() requires default_initializable<_Vp> = default;

       constexpr
-      take_view(_Vp base, range_difference_t<_Vp> __count)
-       : _M_count(std::move(__count)), _M_base(std::move(base))
+      take_view(_Vp __base, range_difference_t<_Vp> __count)
+       : _M_count(std::move(__count)), _M_base(std::move(__base))
       { }

       constexpr _Vp
@@ -2180,8 +2180,8 @@ namespace views::__adaptor
        = default;

       constexpr
-      take_while_view(_Vp base, _Pred __pred)
-       : _M_pred(std::move(__pred)), _M_base(std::move(base))
+      take_while_view(_Vp __base, _Pred __pred)
+       : _M_pred(std::move(__pred)), _M_base(std::move(__base))
       { }

       constexpr _Vp
@@ -3782,8 +3782,8 @@ namespace views::__adaptor
       elements_view() requires default_initializable<_Vp> = default;

       constexpr explicit
-      elements_view(_Vp base)
-       : _M_base(std::move(base))
+      elements_view(_Vp __base)
+       : _M_base(std::move(__base))
       { }

       constexpr _Vp
@@ -3903,14 +3903,14 @@ namespace views::__adaptor
          _Iterator() requires default_initializable<iterator_t<_Base>> =
default;

          constexpr explicit
-         _Iterator(iterator_t<_Base> current)
-           : _M_current(std::move(current))
+         _Iterator(iterator_t<_Base> __current)
+           : _M_current(std::move(__current))
          { }

          constexpr
-         _Iterator(_Iterator<!_Const> i)
+         _Iterator(_Iterator<!_Const> __i)
            requires _Const && convertible_to<iterator_t<_Vp>,
iterator_t<_Base>>
-           : _M_current(std::move(i._M_current))
+           : _M_current(std::move(__i._M_current))
          { }

          constexpr const iterator_t<_Base>&



Thank you again for your great contribution to <ranges>. :)

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
These changes are not strictly necessary.

"base" is a reserved name, because of move_iterator::base() etc.

and "i" is a reserved name, because of operator""i() in <complex>.

So users cannot define those as macros, and so it's safe for us to use them.

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

--- Comment #2 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> These changes are not strictly necessary.
> 
> "base" is a reserved name, because of move_iterator::base() etc.
> 
> and "i" is a reserved name, because of operator""i() in <complex>.
> 
> So users cannot define those as macros, and so it's safe for us to use them.

Extremely reasonable.

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For consistency (and to avoid reports like this one) we might want to uglify
them anyway. But it's not a correctness issue, just stylistic.

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

--- Comment #4 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> For consistency (and to avoid reports like this one) we might want to uglify
> them anyway. But it's not a correctness issue, just stylistic.

I think I might be the only one who would ask for trouble to report this kind
of issue ;-)
By the way, do you plan to respond to Casey's charges against you? It seems to
me that he mistakenly believes that libstdc++ has a bug.

https://github.com/microsoft/STL/issues/2171#issuecomment-908798422

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I need to look into it. He might be right, I'm not sure yet.

[Bug libstdc++/101739] Some function parameters in <ranges> missing uglify

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ppalka at gcc dot gnu.org
   Target Milestone|---                         |13.0
         Resolution|---                         |FIXED

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Looks like the missing uglification has been corrected by
r13-2202-g980e0aa0ce3bdf and r13-2323-g26aafae4e50d1b, so I suppose we could
close this as fixed for GCC 13.