2011/6/6 Gregory Crosswhite <gcross@phys.washington.edu>
Hey everyone,
Since my idea to add I/O operators for none_t has been approved by the community according to the three-week rule --- which as you all know states that any proposals that have received no feedback on the list after three weeks are therefore automatically approved by the community ;-) --- I have written a patch based on the feedback I have received to implement these operators and attached it to this e-mail. To summarize my earlier e-mail, the advantage of having these operators around is that they allow generic I/O code to be applied to data of type none_t.
One decision that I made in this patch that I have mixed feelings about is that I put the operators in the boost namespace. The advantages of this approach are obvious, but the disadvantage is that this "hides" them from the user who might not realize that he or she needs to import operator>> and operator<< in order to access them (since importing qualified operators is something that is not usually done) but instead conclude they they don't exist at all. Alternatives include putting them in the global namespace and putting them in the std namespace. Any thoughts on this?
Since the window for adding new features to Boost closes tomorrow, and this patch is relatively small and should be fairly innocuous, is there a chance that this or something like it could be considered for the next release?
Thanks! :-) Greg
Hi Greg, I personally don't see any use for these operators, nor any harm they could do. About your namespace concern: wolud these operators be found via ADL, if you put them into the same namecpace, as none_helper (that is boost::detail)? Also, did you consider adding these operators to another file (i.e. none_t_io.hpp), so that users of none_t, who (usually) don't need these operators, don't get <iosfwd> on the way? Notice, that boost::none is defined in a separate file too. Regards Kris