C++ Logo


Advanced search

Re: [D1689R5] Draft addition of the `is-interface` key

From: Ben Boeckel <ben.boeckel_at_[hidden]>
Date: Fri, 13 May 2022 17:43:02 -0400
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

> > 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 {
  X x;

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


Received on 2022-05-13 21:42:22