[Daniel]
> While I am sympathetic with your concern, I don't think you need to
> worry about it.

Actually, given what I've gone through since 2015 and all the unfounded accusations that being levelled at me, I have every reason to worry about it. Sorry, that is my experience with WG21 and the C++ devtool ecosystem.

> I was discussing this today on C++Now with a few folks, and after
> re-reading the standard, I think I agree with the opinion that
> requiring an additional flag to produce the binary module interface of
> non-exportable module partitions seems like a bug in MSVC to me.

I would like to understand better the logical steps that lead to that conclusion, and in particular the (sometimes unspoken) assumptions underlying each of those logical steps. Maybe that can help ease the disconnect.

Just so you know - you, Daniel - this is not a rhetorical ask.

-- Gaby

-----Original Message-----
From: Daniel Ruoso <daniel_at_[hidden]>
Sent: Tuesday, May 3, 2022 5:39 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: Ben Boeckel <ben.boeckel_at_[hidden]are.com>; sg15_at_lists.isocpp.org; Tom Honermann <tom_at_honermann.net>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

Em ter., 3 de mai. de 2022 às 18:47, Gabriel Dos Reis
<gdr_at_microsoft.com> escreveu:
> There are several things to consider here. The most worrisome to be is whether that
> practice is essentially closing the door for future standard language evolution where
> an exported module partition can have a module partition implementation.
> That question, for me, is more important than what MSVC is doing today.
> My hope is we are not setting up the new build framework with an implicit "no" to that answer.

While I am sympathetic with your concern, I don't think you need to
worry about it.

The tooling space is profoundly more flexible than the language space,
and if a future version of the language changes its rules I am
confident that build systems would be able to cope with it and support
the new feature (after all Modules were a significantly larger change
anyway).

In that sense, making the environment less ergonomic in the name of a
hypothetical change of the language is not a trade off that I think
makes sense.

I was discussing this today on C++Now with a few folks, and after
re-reading the standard, I think I agree with the opinion that
requiring an additional flag to produce the binary module interface of
non-exportable module partitions seems like a bug in MSVC to me.

Once again, I am confident we can address future language standards
when they move forward, therefore I think forcing the user to
explicitly describe that this is a non-exported module partition is an
undesirable outcome when the tooling would not require that from the
user otherwise in the current versions of the language.

daniel