On Mon, Apr 21, 2014 at 5:09 PM, Alp Toker <[email protected]> wrote: > > On 22/04/2014 00:31, Alp Toker wrote: > >> I'm not really opposed to the idea, though. I just found the current >>> version easier to use. >>> >> >> I recommend not modifying the Diag() signature because the feature will >> be unavailable to other modules until they each update their own Diag() >> signatures introducing latent churn. >> > > To be clear, my concern is that other developers will propagate this over > time to other Diag() functions as they would have to to be able to use it > -- a problem that a fluent extension to DiagnosticBuilder wouldn't suffer > from. > > If it does propagate, that means many signatures will get updated and > locks us in a little more as we look to improve the diagnostic system. > > To me that tips the balance in favour of the fluent approach which is the > straightforward way to provide the feature to all diagnostic emitters > immediately without further change to interfaces. > > I can tell you're keen to get this in from the 10 minute review window but > I'd prefer if you take this measure because it's not much work beyond your > original patch :-)
I think this is a reasonable concern; this is very much a corner-case feature so shouldn't be in the primary interface of Diag(...). I wonder if a manipulator might fit the streaming interface of DiagnosticBuilder a bit better than a fluent interface.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
