>> always use .value_or()/.value() > But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nul

>> always use .value_or()/.value() > But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nullness and write the appropriate if/else block. .value_or() actually does and you can certainly add a lint check against dereferencing optional or using .value() if you’d like. C++ does not Yet provide Case-style syntax for handling variants like rust, outside of macros and the standard library will certainly not define macros. I think what you have done for your codebase makes sense based on your preferences but I think the standard optional works pretty well given the variety of code based and styles it’s intended to support. > It was already severely hazardous with pointers, that's the problem. So then don’t use the dereference operator.