sammccall added a comment. In D72498#1816244 <https://reviews.llvm.org/D72498#1816244>, @ilya-biryukov wrote:
> In D72498#1815500 <https://reviews.llvm.org/D72498#1815500>, @lh123 wrote: > > > - hover over the `front` , you'll see "instance-method `front` → > > `std::vector<int, class std::allocator<int> >::reference`". > > - hover over the `push_back`, you'll see "`std::vector<int, class > > std::allocator<int> >::value_type && __x`". > > > These look terrible and are the great examples where showing canonical types > results in better output than canonical types. > I wonder why we add `std::vector<int, class std::allocator<int>>::` in the > first place, I believe the standard library uses `value_type` in the > declaration. Showing `value_type` is not great, but at least that doesn't > uglify what was written in the code in the first place. > FWIW, I think the perfect output in those cases would be `int (aka > value_type)` Indeed. Another illustrative example, the return type of `vector<int64_t>::at()` - we'd probably want `int64&` here, rather than `vector<...>::reference` or `unsigned long long`/`unsigned long` depending on platform. It seems like: - unwrapping nothing isn't ideal - unwrapping everything isn't ideal - brevity might be a good heuristic, but unclear - there's value sometimes in showing multiple forms, unclear exactly when (Machine learning time? Mostly joking...) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72498/new/ https://reviews.llvm.org/D72498 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
