Investigate std::optional<std::shared_ptr<T>> usage (e.g. ShowField)

[dcwhite]

Summary

Several places in the codebase use std::optional<std::shared_ptr<T>> (or the Handle alias equivalent, e.g. std::optional<ColorMapHandle>). This is redundant — shared_ptr already has a "null" state (empty pointer) that can represent absence, so wrapping it in optional gives two different ways to express "no value" (std::nullopt vs. a null/empty shared_ptr). That's confusing for readers and callers, and invites bugs where one form is checked but not the other.

Known usages

• Modules/Visualization/ShowField.cc — std::optional<ColorMapHandle> colorMap used as a parameter type in multiple function signatures (getNodeRenderState, getEdgeRenderState, getFaceRenderState, etc.), where ColorMapHandle is itself SharedPointer<ColorMap> (see Core/Datatypes/DatatypeFwd.h)
• Reportedly other places in the codebase as well — needs a full sweep

Tasks

• Grep the codebase for std::optional< combined with shared_ptr/Handle-typedef'd types to enumerate all usages
• For each usage, determine intent: is the distinction between "empty optional" and "null shared_ptr" meaningful, or is it accidental?
• Decide on a convention: prefer a plain (possibly null) shared_ptr/Handle, or keep optional and enforce that the inner pointer is never null
• Refactor ShowField.cc and any other identified call sites to follow the convention
• Document the convention (e.g. in a dev doc or code comment near DatatypeFwd.h) so it doesn't reappear

Why this matters

Mixing both null-representations makes call sites harder to reason about ("is colorMap present but null? is that even valid?") and increases the chance of null-shared_ptr dereferences or missed nullopt checks.

[dcwhite]

Found by @basisunus