This can be useful but to avoid confusion, I wouldn't call it a string type at all. Maybe it's an identifier or a symbol or a label or something like that? If you're excluding square brackets, there are probably other special characters you want to exclude too?
Thanks for the feedback, and I'm glad to see other people worry about these details, too!
ASCII control characters are forbidden in the entire WSL file. Then apart from [] everything is allowed.
For practical applications, by far the most important requirement of strings is being able to include space characters to make a short sequence of words, like [Trinidad and Tobago].
I don't know a better word for "sequence of words" than "String". Maybe "Words", but technically it really is a string (containing an arbitrary sequence of the allowed characters). Even approaching the enforcement of more structure would be a lot of work with little returns. And you can't include a literal newline in a C string literal, and you can't even have a NUL character in the interpretation (memory layout) of it, right?
I actually started out with a C-like string as default type (so named it "String") but noticed
- A big problem with string culture is that "" strings use identical start and end markers. A problem which Joe Armstrong mentioned as well.
- Escaping means significantly higher complexity of parsing out the interpretation from the literal, while it's not really needed for most applications.
Both these problems make data unnecessarily hard to process with dirty one-off scripts. So after considering some other options I'm now with [this style] because [] are not too often needed or when needed can often be substituted with (), and are very pleasing on the eye in most fonts.
In conclusion I guess it will stay "String", and other less frequently needed types will be called "CString", "Base64", and "BinaryString". Or optional parameterization will be created for "String" to declare the escaping style without needing a separate metatype.
If you're designing a language it's probably okay to have string literals that can't contain certain characters, so long as there is some other way to do it. It's a bit different for a serialization format.
The question is what you do when you're converting some data from some other format (for example, dumping a database) and there are strings that actually contain these special characters. Even if it's a bit ugly, it's good to have some way to represent the data so that it can be read back in again without any loss. In this kind of tool, you can't just say "don't do that" because the data has already been saved - you're just converting it. (So my idea of not calling it a string type probably doesn't make sense, on second thought, if you want to be able to interoperate.)
Square brackets are an interesting choice. If you just want to do simple lossless escaping, it doesn't seem that hard:
\\ means a literal backslash
\] means a literal ']'
Anything else gets written as-is. (But, what if the database actually does contain control characters in some of its strings?)
