[Daniel]
> Sorry you went through that, I hope you don't see this as an attack to
> you personally.

No, not from you. To this date, you haven't engaged in that even when we disagree on technical matters.

> MSVC is requiring an additional flag when it would be perfectly fine
> (at least on this particular version of the standard) to just produce
> the BMI in all cases.

I absolutely agree with you it would be perfectly fine if I was a compiler writer who *just* had to worry about whether my compiler could perfectly make sense of what the input source is asking me to do. And if I was writing such tools, I would probably say "of course, I can match that; what is what I'm going to do".

However, C++ devtools aren't used in the vacuum and not all the constraints for C++ devtools are the same from the all platforms. One constraint (by far not the only one) for MSVC (as far as modules are concerned with it) is: given these compiler inputs (and options are inputs), they need to know - before the compiler runs - what the output (written files are output) are going to be. The options are "success with these expected files, or error". Just looking around whether the compiler might have left a spare file (or maybe a stale file? Or a malicious file?) is not an option.

Back to the previous assertion that it is an "ergonomic bug", I would say it is an ergonomic bug very much in the way that not including "." in $PATH is an ergonomic bug.

-- Gaby

-----Original Message-----
From: Daniel Ruoso <daniel_at_ruoso.com>
Sent: Tuesday, May 3, 2022 5:50 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: Ben Boeckel <ben.boeckel_at_kitware.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 20:44, Gabriel Dos Reis
<gdr_at_[hidden]> escreveu:
> 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.

Sorry you went through that, I hope you don't see this as an attack to
you personally.

> > 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

It's not a "language lawyer" kind of bug. This is an ergonomics bug.

MSVC is requiring an additional flag when it would be perfectly fine
(at least on this particular version of the standard) to just produce
the BMI in all cases.

I don't have the full context on the decision for why that flag was
added, but I cannot see from the current point in time why that flag
should be required.

daniel