I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place.
You may be right, but you're talking about different use cases. I've got a protocol de/encoders so I want a friendly high level representation of messages that I want to hand off between modules. Imagine a struct with an optional substruct. Valid alternatives: a pointer to the substruct. Even if I can put the second structure on the stack, this might mean less cache hits. The total extra size is also increased bool=>pointer. Another option sometimes possible is a nullable value. FAST-FIX's nullable integer for example increments all non-negative values and uses 0 to represent a null. Another option is to use a presence map at the top of a structure with one bit(or byte) per optional field. That might help with alignment.
I find that it is quite easy to write safe C++ interfaces without using optional...
Yes I used optional because I knew it would do things correctly.
you haven't convinced me
Just focus on #1 first. Not writing to m_initialized in the deconstructor would benifit all use cases of optional. It can't be the solution to just not use boost everytime there's a performance issue.