One reservation I have about “optional” (and for that matter, “shared_ptr” and other objects that directly store their tracking in an object) is that object-ori

One reservation I have about “optional” (and for that matter, “shared_ptr” and other objects that directly store their tracking in an object) is that object-oriented storage models do not necessarily make sense for tiny objects. If you have a lot of optional data, or a lot of reference counts, etc. it can make a lot more sense structurally to gather the state of all variables in one place. For instance: if you have 10 optional fields in a structure, create a single set of 10 bit flags to track them all; the result is much smaller than 10 “optional” objects ever could be. The last thing you want is a ton of padding across millions of objects in your program; this starts to affect everything from efficient use of caches to maximum memory capacity. It just seems a bit of a slippery slope; optional<> might start showing up all over the place as the One True Way To Optional things, without regard for the unnecessary padding and/or wrapping of data. The only way to really do this “for free” is to have the compiler keep track of what was ever set, as Swift appears to do, keeping the tracking out of the memory or run-time footprint.