tonumber doesn't work on true or false

[davidfetter]

It should because arithmetic on booleans is often a clear way to get complicated things done.

[itchyny]

Any example how useful it is? I'm not sure how common this conversion is, and I'm afraid using this tends to make query less readable.

[pkoppstein]

Any example ...

As it happens, I was just working on def kruskal
which requires converting a (strictly) boolean array to an array of 0s and 1s. I would have most likely written
map(tonumber) if that had been possible.

However, I am not sure the pros in this case outweigh the cons, partly because "tonumber" was mainly intended for
parsing numeric strings. If it were to be extended to boolean, why not to other types, notably "null"? Also, even in cases such as def krusal, there is a potential downside to using tonumber in that a stray value such as 2 or "2" would not be caught as an error.

I'm not trying to make a general case against polymorphism, but there is a general case to be made against increasing polymorphism - the point being that it raises issues about "backward compatibility" if broadly understood.

[itchyny]

How about making length work on booleans? I've never heard of length of booleans, but neither of length of null, which already works.

[davidfetter]

Any example ...

As it happens, I was just working on def kruskal which requires converting a (strictly) boolean array to an array of 0s and 1s. I would have most likely written map(tonumber) if that had been possible.

I've been managing to punch out of my weight in speeding things up by sneaking around the monster known to speeders-up of code as The Branch Predictor. Looking at the code folks have written along this line, it's started to look like a nice way to do things even when speeding-up is not the highest goal.

I suppose I could invent some BS about how mapping bools to bits is somehow important in LLMs, but I just won't do that for fashion. I figure it's cool and shouldn't make things worse for those who don't use it.

However, I am not sure the pros in this case outweigh the cons, partly because "tonumber" was mainly intended for parsing numeric strings.

Stuff gets repurposed all the time, so "primarily intended" goes to a reverence for the past that would be a lot easier to justify if jq were all about the strict mathematical definitions, program proving, and so on. Is that the direction the project is going?

If it were to be extended to boolean, why not to other types, notably "null"? Also, even in cases such as def krusal, there is a potential downside to using tonumber in that a stray value such as 2 or "2" would not be caught as an error.

I'm sure I could come up with some strained analogies that didn't apply to the case at hand if I really wanted to, but I don't do that because I don't see them as advancing a discussion, fun as doing that can be.

I'm not trying to make a general case against polymorphism, but there is a general case to be made against increasing polymorphism - the point being that it raised issues about "backward compatibility" if broadly understood.

Serious question. Are there jq code bases whose needs we need to look after with something other than a changelog where this is a big concern?