why-modules.org

Why Modules?

1 Why Modules

Abstract: C++ Named Modules are not about build optimization, although that was an important design consideration. Modules are about controlling visibility and access to names and definitions at a fine-grained level.

This talk will show how to use the various features of modules and the kinds of module units to provide access to the features of your library while hiding the details you don’t want clients to depend on. The talk will also cover some of the limitations and how clients may still end up depending on your details in ways that constrain your ability to maintain ABI compatibility.

Topics and Preliminary Outline

2 Module Syntax and Semantics

2.1 Module units

2.2 Module “Purviews”

2.3 Export

2.4 Import

2.5 Global Module Fragment

2.6 Private Module Fragment

2.7 Instantiation Context

2.8 Reachability

3 Organizing your Module

3.1 Dependency Cycles Are Forbidden

3.2 Single File Unit

3.3 Module Partitions

3.4 Implementation Partitions

3.5 `export import` : sub-modules

4 Planning ahead

4.1 Do you care about ABI or API?

4.2 What do you want to hide

4.3 `inline` means inline

4.4 Module Attachment and Mangling

5 Testing Modules

5.1 Public Interface

5.2 Test Implementation Units