[Daniel]
> I would argue, however, that the portability issues with header units
> will be bigger than what we expect if we don't define this more
> carefully -- which I think the modules ecosystem tr can do.

Agreed, but what can this body (the study group) say more than "your implementation needs to be unambiguous about what it considers importable"?

Also, we don't import module units - we never do.

> Specifically, I would support the notion that library authors have to
> explicitly choose to make a header "importable". As opposed to the
> notion that "anything you could include, you could now import".

Agreed!

-- Gaby

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

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

Ok, I see what you mean.

I would argue, however, that the portability issues with header units
will be bigger than what we expect if we don't define this more
carefully -- which I think the modules ecosystem tr can do.

Specifically, I would support the notion that library authors have to
explicitly choose to make a header "importable". As opposed to the
notion that "anything you could include, you could now import".

daniel