----- Original Message ----- From: "William E. Kempf" <[EMAIL PROTECTED]>
> >> It's trivial to make that a free function like get. Or further, to > >> make a subset API for optional. > >> > > You can certainly do the same with variant. The point is that with > > optional<> it is *easier*. > > With optional<> you don't need to specify the type of the wrapped value > > all the time as with variant; and you don't need to explicitly test if > > the variant holds a "nil_t" in order to see if it is initialized. > > To add my own 2 cents on why we should have optional<> instead of just > relying on variant<T, nil_t> is along the same lines as Fernando is trying > to convey here. A std::pair<int, int> provides all the functionality > you'd need for a "point" type in a GUI framework, but we'd still want to > have a point type (which may be implemented in terms of std::pair<int, > int>) in order to bring the syntax more in line with domain we're dealing > with. The exact same thing applies to optional and variant. > > The argument about optimizing POD cases is less compelling. Even if the > optimization was considered necessary, I'd think you could provide it with > the variant<POD, nil_t> as well (though it would be a trickier > implementation). Oh don't get me wrong. I vote to have an optional. Again, my point is that it should be noted that we can easily write a thin API over the variant that way, we will avoid redundancy of code. Yet of course, that would have to be in the future since we do not have a variant yet. Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
