All The Module Names

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

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.

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:

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:

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