Document number

ISO/IEC/JTC1/SC22/WG21/P1876R1

Date

2019-10-08

Reply-to

Rene Rivera, grafikrobot@gmail.com

Audience

SG2

1. Abstract

This proposes to make module names as flexible as possible for maximal user utility to choose their ideal module organization.

2. Changes

2.1. R1

Minor typo fixes, additional and compelling examples, slight grammar change to allow repeated delimiters, and results from SG15 CppCon 2019 meeting discussion.

2.2. R0 (Initial)

Initial content.

3. Introduction

In P1873 [1] Michael Spencer proposes to remove the “.” from modules names. The rationale being that since the .'s do not have any current semantic they should be removed. With the goal that in some future standard the .'s can be added with the desired semantics.

The status quo counters that leaving the .'s provides users the ability to use .'s as a means to structure modules, through naming, to fit their organizational needs.

If we are allowing users the limited flexibility to use .'s we should strive to give users the maximal flexibility to use module names to express their desired structural, and other, meanings.

4. Proposal

Allow for as many syntactic characters in modules names as possible. This means allowing the following as part of module names: ~, !, @, $, %, ^, &, *, -, =, +, |, ,, ., ?, /, (, ), [, ].

This can lead to some useful categorizations for modules. For example…​

Expressing both organization and optional grouped modules:

boost.mp11
boost.math
boost.math.core
boost.math.common_factor
boost.math.octonion
boost.math.quaternion
boost.math.special_functions
boost.math.statistical_distributions

boost/mp11
boost/math
boost/math.core
boost/math.common_factor
boost/math.octonion
boost/math.quaternion
boost/math.special_functions
boost/math.statistical_distributions

In that we have both the high-level boost/…​ modules which are all encompassing for the particular library. But we also have alternatives of smaller grouped modules of boost/math.octonion which allow for limited code use (in this case only the octonion functionality from Boost Math library). While the difference is not that significant between the status-quo and the expanded names in that example; The advantages to the expanded names becomes apparent when the organization is not strictly hierarchical. For example..

It could also express common combinations of grouped modules:

boost.math.octonion.quaternion
boost.math.special_functions.statistical_distribution

boost/math(octonion+quaternion)
boost/math(special_functions+statistical_distribution)

This gives programmers domain specific useful groupings to fit their application context. And avoids confusion in the meaning placed on the . delimiter.

5. Wording

5.1. [module.unit]

module-declaration:

exportopt module module-name module-partitionopt attribute-specifier-seqopt ;

module-name:

module-name-qualifieropt identifier

module-partition:

: module-name-qualifieropt identifier

module-name-qualifier:

identifier . module-name-delimiter
module-name-qualifier identifier . module-name-delimiter

module-name-delimiter: one or more of

~ ! @ $ % ^ & * - = + | , . ? /
( ) [ ]

6. Review

6.1. SG15, CppCon 2019

An early draft of this paper was reviewed by SG15 in CppCon 2019 (2019-09-21). The discussion centered around what, if any, advantages and disadvantages there would be for tooling to have the extra delimiters. To that end there where two polls taken:

POLL: Tooling suffers if we remove dots from module names. Attendance: 18
Strongly For Weakly For Neutral Weakly Against Strongly Against

4

7

5

0

0

POLL: Post C++20, tooling wants more module name delimiters than just dots. Attendance: 18
Strongly For Weakly For Neutral Weakly Against Strongly Against

2

4

4

4

3

We decisively conclude that there is no consensus on wether the ideas expressed in this proposal.


1. P1873 — remove.dots.in.module.names