sdkrystian wrote:
@cor3ntin This wouldn't fix [the case that abseil users complained
about](https://github.com/llvm/llvm-project/pull/98547#issuecomment-2224998395)
(example reduced from [the
source](https://github.com/abseil/abseil-cpp/blob/master/absl/container/internal/compressed_tuple.h#L256)):
```cpp
template <typename... Ts>
class CompressedTuple
: private internal_compressed_tuple::CompressedTupleImpl<
CompressedTuple<Ts...>, absl::index_sequence_for<Ts...>,
internal_compressed_tuple::ShouldAnyUseBase<Ts...>()> {
template <int I>
using StorageT = internal_compressed_tuple::Storage<ElemT<I>, I>;
public:
template <int I>
constexpr ElemT<I>&& get() && {
return std::move(*this).StorageT<I>::get();
}
};
```
Moreover, this fails to address cases where the base class declares a
non-static data member with the same name as the class template:
```cpp
template<typename T>
struct A
{
int A;
};
template<typename T>
struct B : A<T>
{
bool f()
{
return this->A < 1; // '<' would be interpreted as the start of a
template argument list
}
};
```
I think that implementing CWG1835's resolution as it stands is our best option.
Doing so results in the most consistent behavior (e.g. 'use template when the
object expression is dependent'), the most obvious fixes to achieve the
intended interpretation (i.e. 'add `template` prior to the intended template
name' [as opposed to surrounding the class member access expression in
parentheses]). Given that we can now identify _almost_ all cases where
`template` is missing with this patch and issue a warning, and that these cases
wouldn't be resolved by any of the proposed compromises, I think our best
option is to simply implement the resolution with enhanced recovery/
https://github.com/llvm/llvm-project/pull/100425
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
