Coverage increased (+0.03%) to 84.168% when pulling 9334a4a on itchyny:fix-string-multiplication-regression into a17dd32 on stedolan:master.

This is makes it behave as same as 1.6, but I personally prefer string * number emits "" when 0 ≦ number < 1.

@itchyny - There are certainly good arguments for evaluating String * 0 as "", so much so that I would be happy to open a “bug report” to that effect if you would be willing to make the change. As things are, I often define a helper function to work around the problem. Of course, it’s easy enough to use // but it’s so easy to forget that jq somehow got this one wrong….

@nicowilliams wrote:

I'd like to remove string multiplication

Well, that particular horse is out of the barn, grazing in some
distant field in another country with which we no longer have
an extradition treaty.

Anyway, STRING * NUMBER is well-understood and quite widely adopted.(*)

The thing that is really questionable is NUMBER | length,
which evidently comes from mathematical notation (|...|) but still,
even mathematicians don't pronounce that as "length".

Since that horse too is out of the barn, I would propose that (at least pending jq 2.0):

a) NUMBER | length be officially deprecated.
b) def abs: be added

q.v. #2672

(*) Courtesy of ChatGPT:

Python:
"ab" * 2

Ruby:
"ab" * 2

JavaScript:
"ab".repeat(2);

Perl:
my $result = "ab" x 2;

PHP:
$result = str_repeat("ab", 2);

Elixir:
result = String.duplicate("ab", 2)

Well, that particular horse is out of the barn, grazing in some
distant field in another country with which we no longer have
an extradition treaty.

This is one reason I'd like to have builtin modules, and then we could have jq::v1_6, jq::v1_7, etc., and we could change builtins' behaviors in backwards incompatible ways.

Questions while we're here:
@nicowilliams wrote:
shouldn't ("string") * 0 == ""? null seems very wrong

Yes!!! I think we're all (?) agreed about that. Let's do it!

currently multiplying by a negative number, nan, -nan, infinite, or -infinite yields null -- why not an error, or empty? (well, empty would be harder to arrange here, so let's not go there)

Based on the results (i.e. jq), I think @stedolan sought to avoid raising errors, preferably by giving some meaning to otherwise meaningless expressions (this would help explain the liberal doses of polymorphism), or preferring null to empty (illustrated by index/1).

In the present case, it probably doesn't make much practical difference, except for backwards compatibility. Ergo, I'd stick with null for now.

But let's not make the perfect be the enemy of the good.

Based on the results (i.e. jq), I think @stedolan sought to avoid raising errors, preferably by giving some meaning to otherwise meaningless expressions (this would help explain the liberal doses of polymorphism), or preferring null to empty (illustrated by index/1).

Well, that was before we had a way to catch errors, but sure.

Thanks, I fixed to emit an empty string when repeating a string by 0 (and less than 1). The logic here can be optimized by copying the written string to grow twice and twice, but could lead to another bug so let's do later.

Thanks!

@nicowilliams wrote:

then we could have jq::v1_6, jq::v1_7, etc., and we could change builtins' behaviors in backwards incompatible ways.

One feature (or per @itchyny, either a misfeature or a non-feature) of jq is that jq allows :: prefixes even in the absence of modules. E.g.:

def v1_6::abs: fabs;
def v1_7::abs: if . < 0 then - . else . end;

This seems to be somewhat relevant here, as I'll illustrate in the case of walk, which has a (feeble) implementation in jq 1.6, and for which the proposed improvement for jq 1.7 (see (#2611) entails a backwards-compatibility issue.

Let's suppose that we want to make it easy for someone using jq 1.7 to invoke (or have their existing code use) the 1.6 version. Then we could retain the 1.6 version by adding the jq1_6:: prefix, and point out that users can:

1. use jq1_6::walk; and/or

2 (a). add def walk: jq1_6::walk(f); early enough to any code that assumes the old implementation; or
2 (b). add the two lines:

def walk: jq1_6::walk(f);
def jq1_7::walk(f): walk(f);

This last allows users to have their cake (existing code does not need to be modified) and eat it (use the new walk at the same time, too).

One important question, though, remains: Is this ability to use :: prefixes in this way a bug, a feature, or something else?