Maintainability and Refactoring Impact of Higher-Level Design Features
summary
Argument: types are harder to refactor than functions and templates harder still, with Concepts effectively impossible to change once published. Demonstrated concrete strategies: add aliasing and qualify ADL-dependent calls, stage changes via a compatibility wrapper (legacy_precision) and sweep callers using clang tooling, and rely on abseil-style aliases (abseil string_view) to coexist. Works in practice but is costly, leaves stray breakage (forward-decls, overloads, ADL, tests) and often requires CI, global visibility, and a multi-step refactoring plan.
AI-written summary · about
chapters (14)
- 0:00Intro
- 2:03Evolution of Design Structures
- 5:00Fowler Refactorings
- 6:02Single-Step Refactorings
- 8:55When Single-Step Refactoring Fails
- 16:00Multi-Step Refactoring 101 - Rename a Type
- 30:03Multi-Step Refactoring Is Expensive
- 31:13Can we change functions?
- 32:28Changing return types
- 36:24Can we change usage of "compatible" types?
- 40:06Can we change virtual interfaces?
- 42:00Can we change concepts?
- 47:36Changing concepts
- 51:11Design Abstractions
related talks
01h 35mImpact on maintainability and refactoring for higher-level design features
01h 02mAdvanced Levelization Techniques (part 2 of 3)
19mLanguage Support for Refactorability Decay Prevention
50mRefactoring Is Not Just Clickbait
46mA Type, by Any Other Name
01h 37mC++ And Beyond: Discussion
01h 07mDesign Patterns in Modern C++
01h 00mAdvanced Levelization Techniques (part 1 of 3)