Hello Stephen
2012/12/29 Stephen Frost <sfrost@snowman.net>:
> * Pavel Stehule (pavel.stehule@gmail.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.
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