Noticing a string class was again discussed in the last developer meeting:

https://octave.discourse.group/t/octave-developer-meeting-october-2022/3512

A particular focus was on the string class (again). It might be a candidate for an early addition during the development cycle of Octave 9 (taking leverage of @apjanke’s .m file implementation in the tablicious package). Having that might allow adapting a range of functions to accepting string objects early on (even if a “final” implementation of the string class might be in C++). Decisions for how to transition to the new syntax for double quotes still need to be taken.

I think adding the functions from comment #8 would already be useful for compatibility with Matlab code. Function isstring () could also be modified to be ready for a string class:

-  tf = false;
+  tf = isa (s, "string");

Also attaching my earlier work on a string class with BISTs. Methods needed to be implemented are commented out in the file. They should probably better be added as separate files, e.g., @string/matches.m.

(file #53924)

@Markus: thanks for this. Could your patch be pushed in Octave? I guess "unicode_idx" could be renamed "__unicode_idx__" too.

Very low hanging fruit but I attach possible implementations of convertStringsToChars, convertContainedStringsToChars, convertCharsToStrings and isStringScalar. They, of course, only make sense when the string class will be implemented (esp. convertCharsToStrings) but, like isstring, they can already be useful for compatibility with Matlab.
There is one issue with curly brackets in the help text (example section) but I am not sure how to fix it. Octave's documentation currently already refers to 'strings' when meaning char arrays or row char vectors (see e.g. strfind) -- I tried to be more explicit for the help text of these functions but it might still require perfecting.

(file #51543, file #51544, file #51545, file #51546)

Gotcha. Thanks.

For the sake of discussion, here's an example of how a @string array could be implemented as a userland M-code class built on top of cellstrs: https://savannah.gnu.org/bugs/download.php?file_id=45939

It supports lexical casting and various other type conversions.

This approach works decently for string data analysis by users: it's a usable datatype, and functions aimed at string manipulation will work well on it. For text data sets, a user can create @string arrays and work with them usefully.

Where it works less well is all the various functions that take strings as incidental arguments, like the plotting functions, property getter/setters, statistical functions that take name/value pair arguments, and all the various other miscellaneous functions. Packages (e.g. from Octave Forge) will also not be @string-aware unless explicitly coded to be so.

Also, since this is based on cellstrs, the underlying "character" semantics are still those of Octave chars. (That is, bag-of-bytes interpreted via context or user locale settings? I'm not actually sure exactly how Octave chars work.)

> String array is a fundamental type, not a cell array, and follows different rules for lexical casting from other types and so on.

Could you elaborate on that a bit? What is "lexical casting"?

In terms of workarounds, it is quite easy not to use this specific feature of Matlab if you want to exchange scripts between the two environments.  Just use the regular cell string construction operator if you do, in fact, want a cell array.

str = {'Good' 'Morning'}

Not sure if you guys noticed but MATLAB recently introduced String arrays which may conflict with Octave's use of the double-quote "" versus ''.

So

str = ["Good" "morning"]

now produces a valid 1x2 string array.