Notes from C++ static analysis

[Jonathan M Davis]

On Wednesday, June 26, 2013 19:18:27 Andrei Alexandrescu wrote:
> On 6/26/13 1:50 PM, bearophile wrote:
> > Andrei Alexandrescu:
> >> Actually this is good because it allows to customize the format string
> >> to print only a subset of available information (I've actually used
> >> this).
> > 
> > Your use case is a special case that breaks a general rule.
> 
> There's no special case here.

I have never heard anyone other than you even suggest this sort of behavior. 
Granted, I may just not talk with the right people, but that at least makes it 
sound like what you're suggesting is a very special case.

> > That
> > behavour is surprising, and it risks hiding some information silently.
> 
> Doesn't surprise me one bit.

Well, it shocks most of us. We expect the number of arguments to a function to 
match the number of parameters, and with format strings, you're basically 
declaring what the parameters are, and then the other arguments to format or 
writefln are the arguments to the format string. Most of us don't even think 
about swapping out the format string at runtime.

> > I
> > think format() is more correct here.
> 
> I think it has a bug that diminishes its usefulness.

It's a difference in design. It's only a bug if it's not what it was designed 
to do. And I think that it's clear that format was never designed to accept 
more arguments than format specifiers given that it's never worked that way. 
That doesn't necessarily mean that it _shouldn't_ work that way, but the only 
bug I see here is that the designs of writefln and format don't match. Which 
one is better designed is up for debate.

> > If you want a special behavour you
> > should use a special function as partialWritefln that ignores arguments
> > not present in the format string.
> 
> That behavior is not special.

Well, it's special enough that most of us seem to have never even thought of 
it, let alone thought that it was useful or a good idea.

I don't know whether it's really better to have format and writefln ignore 
extra arguments or not. My gut reaction is definitely that it's a very bad idea 
and will just lead to bugs. But clearly you have use cases for it and think 
that it's very useful. So, maybe it _is_ worth doing. But I'd be inclined to 
go with Bearophile's suggestion and make it so that a wrapper function or 
alternate implementation handled the ignoring of extra arguments. Then it 
would be clear in the code that that's what was intended, and we would get the 
default behavior that most of us expect. An alternative would be a template 
argument to writeln and format which allowed you to choose which behavior you 
wanted and defaulted to not ignoring arguments.

- Jonathan M Davis