Allow bitwise operations on strings

[altenbach]

Boolean operations support booleans (of course!) and integers. In the case of integers, the operations are performed bitwise.

After reading this discussion, I propose that strings should also be supported as inputs for boolean logic operations, in which case the operation would also be bitwise.

Is there any scenario where this would be a problem?

[Darin.K]

Hey why not, it simplifies the code to flip the case of a string.

[altenbach]

Of course there is no distinction between a 1 character string and a multi-character string (as we have between scalars and arrays, for example). In your case we would want to allow a mixed operations, with a string input and a U8 numeric input to sort things out as intended.

Without adjustments, your code would end up with an "A" result after blindly implementing this idea. (for two arrays, the shorter one wins and I would expect the same for strings)

[Darin.K]

This of course is one in a very long list of things which would be made possible by treating strings as the byte arrays they are...

[SteveChandler]

I feel this may cause confusion to new users. They would mistakenly assume that a string is no different than a simple true/false datatype. Kidding of course - kudos!

[tst]

>...by treating strings as the byte arrays they are...

What about Japanese/Chinese and Unicode?

[Darin.K]

Japanese, Chinese, Sanskrit, and whatnot are simply interpretations of the underlying byte array just like ASCII. My point is simple, any operation which makes sense when wrapped in To/From Byte array primitives should be able to take strings directly. This is one of those.

[Mr.Mike]

---

@altenbach wrote:

Boolean operations support booleans (of course!) and integers. In the case of integers, the operations are performed bitwise.

After reading this discussion, I propose that strings should also be supported as inputs for boolean logic operations, in which case the operation would also be bitwise.

Is there any scenario where this would be a problem?

---

I don't think it's wise to treat strings as byte arrays.  Yes, it's true that LabVIEW currently does that.  That's a behavior I'd like to see change.  I pointed out some reasons why you shouldn't treat strings as data on LAVA a few weeks ago.  I think encouraging their use as data will impede this effort and undermine the appropriate understanding of how strings should be used.

---

@Darin.K wrote:

Japanese, Chinese, Sanskrit, and whatnot are simply interpretations of the underlying byte array just like ASCII. My point is simple, any operation which makes sense when wrapped in To/From Byte array primitives should be able to take strings directly. This is one of those.

---

That may be the case as it is now, but I don't think it should be that way.  You shouldn't make assumptions about how the underlying bytes map to characters.  In an ideal world you would make no assumptions about the underlying data -- you should only care that you have an ordered sequence of characters: a string.  How the string is represented internally is up to the operating system.  The internal representation may be UCS-2, UTF-16, UTF-32, or something completely different.

[Darin.K]

I have only been using LV for about 20 of its 25 years but no matter how much it makes sense I think the Strings as [U8] ship has sailed. At best we may get a new text type that abstracts text from its encoding. It is not like it was rogue users, but NI itself that pushed strings as data. I could make a compelling case that indexing arrays from 0 makes little sense in a ByVal language, but that is also a choice we are used to and sometimes rationalize. [OT] I would like a string like indicator that could provide different views into the underlying data without forcing a copy. I like a hex display of a byte or word array, or sometimes binary, or sometimes ASCII. Array indicators are bloated and show very limited number of elements, string indicators are more efficient but require some data copies and type casting.