zygoloid wrote: > None of the implementations seem to agree with the resolution of the DR: > https://godbolt.org/z/a7nEvW5Gr
Yeah, I think this is a case where the wording is clear and everyone implements it, but it doesn't actually do the right thing. The example in the issue "ought to be" ill-formed, because as the issue points out, there's no reason to think that the N object is actually a base subobject of P, so access to its protected base B shouldn't be granted to a P object. I think a rule even more similar to [class.protected] should be implemented: if we rely on a conversion from a class `N` to a class `B`, if `N` is a protected base class of `B` (if a public member of `B` would be a protected member of `N`), then additionally require that `N` is either `C` or a class derived from `C` (where `C` is the class granting access, as in [class.protected]). I'd suggest we implement that as a warning, given that the standard is clear and other implementers accept. In any case, this new testcase looks good to me, and would be good to add regardless of what CWG ends up deciding here (if they ever make a decision...). https://github.com/llvm/llvm-project/pull/67948 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
