New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
please correct perlfunc to tell when "sprintf @..." is useful #16107
Comments
From perl-diddler@tlinx.orgCreated by perl-diddler@tlinx.orgIn perlfunc.pod, it says: Unlike "printf", "sprintf" does not do what you probably mean when For a language that is describe as a DWIM language, and where the It seems it would be more useful, to know how the current behavior of Alternatively, if there are no examples where the current behavior is I tried searching through a 2.8G CPAN-author tree using zgrep and Perl Info
|
From @iabynOn Wed, Aug 09, 2017 at 10:53:47PM -0700, Linda Walsh wrote:
The prototype for sprintf is '$@'. This was possibly a bad choice at the Our two main choices are: 1) leave it as-is. In this case, 'sprintf @a' gets compiled as 'sprintf scalar(@a), ()' Note that a couple of other ops have the '$@' prototype too; in Arguably we could add a warning if the first arg of sprintf/pack/join is 2) Change sprintf's prototype to '@' so that it becomes a normal list $x = sprintf my_fmt(), @args my_fmt() is now called in list context, and may start to return something
These two searches http://grep.cpan.me/?q=sprintf%5Cs*%40 show about 50 CPAN distributions which are (probably incorrectly) doing sprintf @array ... While a search for sprintf(foo(... shows about 100 distributions. In some of those 'foo' is 'qq', but plenty So I don't think changing the prototype is a viable option. -- |
The RT System itself - Status changed from 'new' to 'open' |
From perl-diddler@tlinx.orgDave Mitchell via RT wrote:
FWIW, sprintf stick out more, for me, as it doesn't follow fprintf
While I'd prefer the functionality, the warning would be a reasonable
Never seen that "tool"/site before. Looks useful....
I'd think it to be a good thing if an automated-type message could be
On the surface, I'd tend to agree, however, one question is -- The second issue obviates the need of considering the 1st case, and that I.e. sprintf requires a format statement -- it will die at that point The only way 'foo(...)' would return something different is if it If it was expecting to return a SCALAR HASH -- then recent changes In the other two cases, SCALAR ARRAY, or a reference, it's still I.e. can you think of what a function might return that would be If it is the case that no function can return valid input to sprintf
|
From @iabynOn Mon, Aug 14, 2017 at 11:57:31AM -0700, L A Walsh wrote:
As a trivial (if slightly contrived) example: my @formats = qw(%s%s %s-%s a=%sb=%s); print scalar f(), "\n"; which outputs %s%s -- |
From perl-diddler@tlinx.orgDave Mitchell via RT wrote:
Considering that we are talking about using I.e. the non-scalar case as passed to the 1st argument of If you felt such faulty code was a possibility, might not an Admittedly, also a bit of a contrived example, but many years ago However, if you really believe there is a reasonable chance that If such usage is considered a "non-pattern", poor, or a 'bug', However, if it is desired to protect such code, then fixing the behavior Either way, it seems the current behavior is only lending it self to |
From @iabynOn Mon, Aug 14, 2017 at 02:28:33PM -0700, L A Walsh wrote:
I used a non-sprintf example purely to demonstrate that a function can Here's an example with sprintf: my @formats = qw(%s%s %s-%s a=%sb=%s); sub simple_output { sub complex_output { $x = simple_output("a", "b");
I don't think my code examples are faulty.
Any non-backwardly compatible change we make requires a value judgement
The two are not alike. The perl case is documented behaviour, which
I'm not saying that the current behaviour is particularly useful, merely
There is a third option: to recognise that the first argument being in I am in favour of adding a warning. -- |
From zefram@fysh.orgThere is nothing to change here. sprintf with an array as first argument -zefram |
From @iabynOn Fri, Dec 15, 2017 at 07:19:54AM +0000, Zefram wrote:
I still intend at some point to add a warning when the first arg of sprintf @foo ... since that almost certainly represents a coding error. -- |
Migrated from rt.perl.org#131875 (status was 'open')
Searchable as RT131875$
The text was updated successfully, but these errors were encountered: