Thank you all for your responses and for the awesome feedback. I think there are a couple of different ideas in this thread. While it would be fantastic to try and find uninitialized values in arbitrary code, that would definitely be a much larger change and I don't think I'm up for that yet. It looks like -Wuninitialized currently follows the flow of uninitialized variables within a function and could probably be modified to also follow members not in the initializer list through the constructor. However, following flow into other functions can be very complicated and, as Matthieu brought up, it isn't possible in the general case because the source for some methods might not even be available. Such a diagnostic would end up being an approximation and would sometimes either have to reject valid code or silently ignore invalid code.<div>

<br></div><div>I guess the warning I was envisioning was more of a stylistic warning. The equivalent warning from gcc is -Weffc++ which includes warnings about violations of several style guidelines from Scott Meyers' book "Effective C++, Second Edition" including this warning (always put all members in the initializer list). It includes a few other warnings and is helpful in preventing mistakes, especially for beginners, but generates a lot of noise when run on large existing projects and unfortunately can't be split into separate, fine-grained warnings. The warning in this patch is much more targeted but makes the choice to reject some valid code instead of silently ignoring invalid code. It was more targeted for beginner to intermediate users of C++ and not for large, highly optimized projects. Maybe this wants to be two warnings, one for initializer lists as it is currently and one that attempts to trace uninitialized members to the end of each constructor but doesn't warn when it isn't sure?</div>

<div><br></div><div>- Evan</div>