On Mon, Jan 21, 2013 at 3:54 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/22/13 7:49 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jan 21, 2013 at 3:33 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/22/13 3:57 AM, Antony Polukhin wrote:
I've got some nice idea from discussion: nullable variant. If many
people use or want to use a variant with a type, that represents empty state, we can create a separate nullable variant class. I think that nullable variant can be implemented more efficient that the current variant. For example we can simplify copy/move constructors and assignment operators, guarantee fast noexcept default construction, simplify metaprogamming and reduce compilation times. Maybe someone want to implement it?
I like it! If you implement it, I'll be your first user :-) I don't really care much about this "never empty" guarantee and I think it's not really worth the trouble.
How is this different from variant< blank, ... > ?
Less work behind the scenes.
You mean fewer LOC / simpler implementation (believable) or faster compiled code (I'd be skeptical)?
Lighter TMP load.
Agreed, but I'm not sure how much the "never empty guarantee" accounts for the present TMP load. better noexcept
guarantees. Etc.
I don't see this. I would think constructing blank has the same noexcept guarantees as assigning a pointer to null, and can equally well be propagated out to the variant interface. You might have a specific case in mind, though? Do you presently use variant< blank, ... >? If not, is it because of the above reasons? - Jeff