<p dir="ltr"><br>
On 28 May 2014 23:01, "Ben Langmuir" <<a href="mailto:blangmuir@apple.com">blangmuir@apple.com</a>> wrote:<br>
><br>
><br>
>>><br>
>>> What’s unexpected to me is that changing a header whose contents are not usually visible may still require rebuilding all of my .cpp files.<br>
>>> module Foo { module One { header “One.h” } module Two { header “Two.h” } }<br>
>>><br>
>>> // One.cpp - I don’t want to rebuild when Two.h changes<br>
>>> #import <Foo/One.h><br>
>>><br>
>>> Do we agree that this is unnecessary if submodules cannot accidentally be affected by changes in other submodules they don’t import (and we have some way to get the set of dependency files for just the submodule)?<br>

>><br>
>><br>
>> No, I don't agree with that. One.cpp might inline some function definitions from Two.h, for instance. Or it might fail to build because it declares something that conflicts with something in Two.h.<br>
><br>
><br>
> I feel like I”m missing something - how is that different from One.cpp having conflicts with some completely different header or module that is not imported into that particular TU?</p>
<p dir="ltr">If you import any part of a module, you have the whole module as part of your translation unit, even though only some of it might be visible. Thus we will diagnose your declarations that conflict with unimported portions of an imported module.</p>