C++ Logo

sg15

Advanced search

Re: [Tooling] [Ext] Modules and tooling: Resolving module import declarations

From: Nicolai Josuttis <nico_at_[hidden]>
Date: Sat, 1 Sep 2018 10:04:00 +0200
Am 31.08.2018 um 18:36 schrieb Gabriel Dos Reis via Ext:
>
>
> | -----Original Message-----
> | From: Ext <ext-bounces_at_[hidden]> On Behalf Of Jason Merrill
> | Sent: Thursday, August 30, 2018 2:43 PM
> | To: Evolution Working Group mailing list <ext_at_[hidden]>
> | Cc: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>; C++ Library
> | Evolution Working Group <lib-ext_at_[hidden]>
> | Subject: Re: [Ext] Modules and tooling: Resolving module import declarations
> |
> | On Wed, Aug 29, 2018 at 1:06 PM, Tom Honermann <tom_at_[hidden]>
> | 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

Received on 2018-09-01 10:14:52