[Tooling] [Ext] Modules and tooling: Resolving module import declarations
Nicolai Josuttis
nico at josuttis.de
Sat Sep 1 10:04:00 CEST 2018
Am 31.08.2018 um 18:36 schrieb Gabriel Dos Reis via Ext:
>
>
> | -----Original Message-----
> | From: Ext <ext-bounces at lists.isocpp.org> On Behalf Of Jason Merrill
> | Sent: Thursday, August 30, 2018 2:43 PM
> | To: Evolution Working Group mailing list <ext at lists.isocpp.org>
> | Cc: WG21 Tooling Study Group SG15 <tooling at open-std.org>; C++ Library
> | Evolution Working Group <lib-ext at lists.isocpp.org>
> | Subject: Re: [Ext] Modules and tooling: Resolving module import declarations
> |
> | On Wed, Aug 29, 2018 at 1:06 PM, Tom Honermann <tom at honermann.net>
> | wrote:
> | > What might such an industry standard approach look like? Here is a sketch
> | > of a design:
> | >
> | > A (set of) module description file(s) that specifies:
> | >
> | > A map from a module name to the file name for the module interface unit
> | > source code. A default naming convention could also be adopted, though
> | we
> | > already have two competing conventions (.cppm vs .ixx).
>
> | This does need a naming convention, as you say.
>
> That does not necessarily follow. All that is needed is a mapping - that mapping could be naming convention, or literally a mapping stored in a file or some other form.
Please, do NOT make the mistake again that we can't agree on a
header/source file extension and therefore have chaos.
Especially the decision to have no extension at all for standard header
files caused a nightmare.
As .cpp these days is by far most common, .cppm sounds fine for me.
--
Nicolai M. Josuttis
www.josuttis.de
PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0
More information about the Tooling
mailing list