Em sex., 13 de mai. de 2022 às 09:23, Gabriel Dos Reis
<gdr_at_[hidden]> escreveu:
> I wouldn't go as far as saying that the implementation being
> able to produce or non produce a BMI means that a translation
> unit is importable or non-importable. Success of producing the
> BMI may happen either because of intentional support
> or sheer happenstance.

I am not sure I understand. The language is defined in a way that is
way more specific than what you're describing here. Units that are
importable must always have a BMI associated with them in the build
process, units that are not importable never have a BMI.

1) "export module Foo": The primary interface unit always must have a
BMI, if the build system doesn't produce it, the module is not really
usable.

2) "export module Foo:Bar": A module interface partition also must
always have a BMI, and it should always be reachable from the primary
interface unit, and it also must be re-exported.

3) "module Foo:Internal": An internal partition (or whatever name we
settle) also must always have a BMI, as it defines the declarations
(and potentially some definitions) in a partition. That partition may
be reachable by the primary interface unit or not, but "module
Foo:Internal" is only useful when some unit in the module does "import
:Internal".

4) header units also will always need a bmi, although that is
controlled by the build system, and it doesn't really show up in the
language itself, except from the caller side.

But those are the *only* cases where a BMI should be produced, and in
those cases they should *always* be produced. There's no ambiguity
here.

The only units in the module that don't have a BMI are the
implementation units (i.e.: "module Foo;"), and those *never* have a
BMI.

daniel