| Message ID | 027d6c9f6afd6b64a279cb698454309c1898f6a1.camel@gnu.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] libstdc++: Count pretty-printed tuple elements from 0 not 1 | expand |
On Mon, 14 Jun 2021 at 19:14, Paul Smith via Libstdc++ <libstdc++@gcc.gnu.org> wrote: > > std::tuple elements are retrieved via std::get<> (template) not > [] (array); have the generated output string match this. Both of your patches seem to be based on the idea that the output is supposed to correspond to how you access the tuple, but that isn't meant to be the case. The fact we show [1] isn't suppose to mean you can access that element as tup[1]. For example, the std::set printer shows: $1 = std::set with 3 elements = {[0] = 1, [1] = 2, [2] = 3} This isn't supposed to imply that you can access the member as s[0]. However, it does use a zero-based index! I think using a zero-based index for tuples makes sense too, although your patch will cause testsuite failures, won't it? The test needs to change too.
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py index 14a6d998690..0063a3185a6 100644 --- a/libstdc++-v3/python/libstdcxx/v6/printers.py +++ b/libstdc++-v3/python/libstdcxx/v6/printers.py @@ -567,7 +567,7 @@ class StdTuplePrinter: if len (fields) > 0 and fields[0].name == "_M_head_impl": impl = impl['_M_head_impl'] - out = '[%d]' % self.count + out = '<%d>' % self.count self.count = self.count + 1 return (out, impl)
std::tuple elements are retrieved via std::get<> (template) not [] (array); have the generated output string match this. libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py (StdTuplePrinter): Use <> not []. --- The previous patch seems uncontroversial to me. I don't know about this one: I'm not sure if there's any precedent for this type of output although to me it looks better since tuples cannot be retrieved via array indexing. libstdc++-v3/python/libstdcxx/v6/printers.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.28.0