On Fri, May 13, 2022 at 17:17:25 -0400, Daniel Ruoso wrote:
> Em sex., 13 de mai. de 2022 às 16:36, Ben Boeckel via SG15
> <sg15_at_[hidden]> escreveu:
> > Attached is a draft of P1689R5
>
> Is it? Maybe the mailing list ate it?

No, after re-reading umpteen times, I forgot to actually do it. See the
sibling reply to the original message to avoid burying it in a
subthread.

> > For C++, this means "has the `export` keyword. In order to avoid a
> > bikeshed round of meeting time, I'd like to read the winds as to how
> > this should be named:
> > - `"is-interface"` (defaults to `true`): the draft has this
>
> I second that opinion. It is consistent with the terminology we discussed.
>
> > Orthogonally, there's also the question of:
> > - no default value (it must always be present in the file)
>
> I think having no default is the correct thing to do. You could have a
> default of null, if we want to allow it not to be specified. Then any
> tooling that needs to know and doesn't receive knows it can't presume
> one way or another. I'd argue it's cheap enough to identify that it
> shouldn't be optional, though.

Something either is or is not part of the interface. I don't see how an
"I dunno" answer is at all confidence-inspiring about a scanner's other
information it is supposed to be providing.

> > Note that, as far as I know, the only reason we need this information
> > for building modules in the first place is to provide the appropriate
> > `-interface` or `-internalPartition` flag to MSVC for compilation for
> > the source file.
>
> Yes, it would be nice if there was a "-importableUnit" so the tooling
> wouldn't have to care.

If that was the flag, there'd be no need for the build to care about
`export` at all.

> > Is this useful for static analysis or other tools as
> > well (AFAIK, this information is readily available by anything that can
> > read the source anyways)?
>
> Yes, but it would likely result in a second read of the source file.
> If the compiler is already reading it to get the dependencies, so I
> can see tooling decide *not* to care about the non-interface files.

They still might care for things like:

```
export module blah;
import :internal; // provides X

export struct Y {
private:
  X x;
};
```

so that `sizeof(Y)` can be computed. I really don't see that it is
completely ignorable without reading the files anyways.

--Ben