C++ Logo


Advanced search

Re: P2581R0: Specifying the Interoperability of Binary Module Interface Files

From: Daniel Ruoso <daniel_at_[hidden]>
Date: Tue, 3 May 2022 20:38:35 -0400
Em ter., 3 de mai. de 2022 às 18:47, Gabriel Dos Reis
<gdr_at_[hidden]> 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

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.


Received on 2022-05-04 00:38:47