[Daniel]
> The language is defined in a way that is way more specific than what you're describing here.

Beyond saying that certain standard library headers are importable and modules are used through import, the language doesn't say much. It defers to implementations.
The only time there might be any portability concern around "importable" is when you have header units.
I am suggesting to continue to defer to implementation in a way that is even more practical.

PS: the able in "importable" is about ability to import. It is an uninteresting notion for modules; the only time it is interesting is when we have headers 😊

-- Gaby

-----Original Message-----
From: Daniel Ruoso <daniel_at_ruoso.com>
Sent: Friday, May 13, 2022 6:48 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: sg15_at_[hidden]
Subject: Re: [SG15] Revisiting terminology, framing for meeting on 2022-05-13

Em sex., 13 de mai. de 2022 às 09:23, Gabriel Dos Reis
<gdr_at_microsoft.com> 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