When I said “glorified header files”, I didn’t mean literally textual inclusion of the primary module interface file - obviously, that can’t work for a variety of reasons. Rather, I meant a processing where work is duplicated, as if header files, with special modifications - not all expressible in Standard C++ - for the semantics of declarations: the global module fragment stays unmodified; macro isolation applies; non-template function definitions are erased to non-defining declarations; class definitions are retained; template definitions are retained; constexpr variables are made inline; module boundaries are enforced during lookup and overload resolutions, thanks to module ownership; etc.


— Gaby

> On Mar 4, 2019, at 5:02 AM, Ben Craig <ben.craig_at_ni.com> wrote:
>
> I do mean textual inclusion, though I can be convinced otherwise. Textual inclusion (with extra generated pragmas) should make it much easier to keep tools like distcc and cppcheck happy in the short term. I suspect that those tools don't want to crack open a BMI to figure out which other BMIs need to be found.
>
> Tools that (think they can) parse C++ will still need to understand these pragmas in order to provide the right macro, visibility, and reachability behaviors, so some work will still be required on their part, but at least they won't need to understand new binary formats.
>
> That said, Mathias Stearn raised an interesting point... I'm not sure how onerous it is for implementations to drop non-macro symbols. A pragma marking the end of a module gives the implementation the information it needs, but that doesn't mean it's easy to remove elements from the data structure. The BMI model likely makes it easier to never add private symbols in the first place.
>
>> -----Original Message-----
>> From: Nathan Sidwell <nathanmsidwell_at_[hidden]> On Behalf Of Nathan
>> Sidwell
>> Sent: Monday, March 4, 2019 8:51 AM
>> To: modules_at_[hidden]; Ben Craig <ben.craig_at_ni.com>; WG21 Tooling
>> Study Group SG15 <tooling_at_open-std.org>
>> Subject: [EXTERNAL] Re: [isocpp-modules] Round2: Path to modules with old
>> bad build systems
>>
>>> On 3/2/19 1:03 PM, Ben Craig wrote:
>>>
>>> Some quick notes on this implementation strategy:
>>> * Uses TEXTUAL inclusion
>>> * Compiler assumes that the build system knows nothing of BMIs
>>> * Compiler needs to be able to do module mapping with minimal input
>>> from users.
>>
>> Do you literally mean textual inclusion or do you really mean dynamically
>> produce an internal-only BMI object?
>>
>> nathan
>>
>> --
>> Nathan Sidwell
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]rg
> Subscription: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C06344e156b854092450208d6a0b27795%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873085702512645&amp;sdata=qM%2FmOqRVA81hUKZiOUJOotig4lYc33qg7p8eU8EZ84w%3D&amp;reserved=0
> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0120.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7C06344e156b854092450208d6a0b27795%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873085702523047&amp;sdata=6auBsrmwiCZ5IocDsVd5d1DzgW6rj2mMvHp0Lw9IxHQ%3D&amp;reserved=0