Lawrence Crowl <cr...@google.com> writes: | On 7/1/12, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: | > On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl <cr...@google.com> wrote: | >> Resend, as I replied to a message that didn't have the usual suspects | >> on the cc line. | >> | >> On 6/27/12, Lawrence Crowl <cr...@google.com> wrote: | >>> ..., does anyone object to removing the permission to use C++ | >>> streams? | >> | >> Having heard no objection, I removed the permission. | > | > This is an area where I think we should not be too prescriptive. | > Clearly, the diagnostics machinery will be used for anything | > diagnostics -- so whether IOStreams are allowed or not would | > not change that. On the other hand, I feel we should defer to | > maintainers' discretion in specific areas whether people are | > implementing dumping or other I/O facilities not related to | > diagnostics, since as I you correctly pointed out, there is an | > added value of flexibility and expressivity. | > | > In summary: Instead of blanket ban, I would suggest that uses for | > C++ I/O streams be reserved for non-diagnostics purposes and left | > at the discretion of maintainers. | | Given that maintainers have discretion to grant exceptions | anyway, would you be willing to let the wording stand without | that permission?
My concern is that this might be construed later in forms that weren't intented, which is why I have been reluctant about prescriptive guidelines. | | I'd like to get the document committed in some form so that we can | make progress on the dependent activities. At present, none of | those activities depend on this issue. Agreed. -- Gaby
