Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used

2012/12/30 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> Hello Stephen
>
> 2012/12/29 Stephen Frost <sfrost(at)snowman(dot)net>:
>> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>>> ok, so what is proposed solution?
>>
>> My recommendation would be to match what glibc's printf does.
>>
>>> I see two possibilities - a) applying my current patch - although it
>>> is not fully correct, b) new patch, that do necessary check and raise
>>> more descriptive error message.
>>
>> Right, have a new patch that does error-checking and returns a better
>> error on that case, update the docs to reflect that restriction, and
>> then (ideally as an additional and independent patch..) implement the
>> width capability (and, ideally, the ability to pass the width as an
>> argument, as glibc supports) which matches the glibc arguments.
>>
>> Part of the reason that this restriction is in place, I believe, is
>> because glibc expects the width to come before any explicit argument
>> being passed and if an explicit argument is used for width then an
>> explicit argument has to be used for the value also, otherwise it
>> wouldn't be clear from the format which was the argument number and
>> which was the explicit width size.
>
> I found one issue - if I disallow mixing positional and ordered style
> I break compatibility with previous implementation.
>
> so maybe third way is better - use fix from my patch - a behave is
> same like in glibc - and raise warning (instead errors) when mixing
> styles is detected - we can replace warnings by errors in future.

this is exactly what gcc does - and without breaking applications.

>
> What do you think?
>
> Regards
>
> Pavel
>>
>> I don't think it's a good idea to come up with our own format
>> definition, particularly one which looks so similar to the well-known
>> printf() format.
>>
>>> I have not strong preferences in this topic - both variants are
>>> acceptable for me and I invite any community opinion. But current
>>> state is not intuitive and should be fixed.
>>
>> Agreed.
>>
>> Thanks,
>>
>> Stephen