indirect_value
indirect_value copied to clipboard
Make null-state non-observable
Work in progress, does not compile.
Codecov Report
Patch coverage: 99.05
% and project coverage change: -0.71
:warning:
Comparison is base (
4ac5a7e
) 99.79% compared to head (84e2a7b
) 99.09%.
Additional details and impacted files
@@ Coverage Diff @@
## main #103 +/- ##
==========================================
- Coverage 99.79% 99.09% -0.71%
==========================================
Files 5 6 +1
Lines 986 885 -101
==========================================
- Hits 984 877 -107
- Misses 2 8 +6
Impacted Files | Coverage Δ | |
---|---|---|
pimpl.h | 100.00% <ø> (ø) |
|
pimpl_test.cpp | 100.00% <ø> (ø) |
|
indirect_value.h | 93.75% <94.64%> (-6.25%) |
:arrow_down: |
indirect_value_test.cpp | 99.63% <100.00%> (-0.12%) |
:arrow_down: |
optional_test.cpp | 100.00% <100.00%> (ø) |
|
pimpl.cpp | 100.00% <100.00%> (ø) |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
A couple of consequences of these changes. It no longer makes sense to compare indirect_value against nullptr as it now had no observable null state.
However, the construction interface now diverges from that of polymorphic value. Default construction of indirect_value is contingent upon the underlying T being default constructible. But default construction of polymophic_value has been removed (well hidden as a private method) as now there is no observable null state there it does not make sense to allow default construction (as the underlying derived type must be known to do this)
Should we make indirect_value
non-default constructible or should we live with the API difference?
From a teachability standpoint, symmetry is appealing.