4 ms·

I wish more languages had primitives for "simple strings". Most of the time when I use a string I could live with a restriction that it's ascii only and can fit

I wish more languages had primitives for "simple strings". Most of the time when I use a string I could live with a restriction that it's ascii only and can fit in 64bytes. "Programming string" vs "human string". For example a textual value of some symbol or a name of a resource file I can control myself or a translation lookup key (which I can make sure is always short and ascii). An XML element name or json property in an enormous file with a schema I control. It seems weird to use the same type for the "human string" e.g. user input, a name, the value looked up from the translation key and so on. For the simple strings it feels like making heap allocations, or either using two bytes per char (e.g C#) or worrying about encoding in an utf-8 string (e.g. Rust) are both wasteful.

brundolf 6y ago
You can pretty much do this in Rust: let simple_str: &[u8] = b"hello world"; println!("{}", simple_str[6] as char); // 'w' Though I would advise against it in most cases, because even many "non-human" formats like XML and JSON do allow for Unicode characters
- sedatk 6y ago
  Filenames too.
  - alkonaut 6y ago
    There is no problem making filenames that are bound ascii. Just because they can be non-ascii on most OS'es, doesn't mean they are (when I myself control all input - that's the key). I think it's the problem of generality here. If I make a game that has thousands of texture files I want to store in a lookup table and it saves me x ns on the lookup if those textures are in a dictionary with 1-byte characters vs 2-byte character keys, then I could just make sure my file names are ascii. So I have a collection of 2000 ascii file names. I don't care whether the rest of the files outside my game textures are, or could be, non-ascii.
    - Narishma 6y ago
      You shouldn't be using strings in that case anyway, especially if performance matters.
bsder 6y ago
I would say UTF-8, but I really do miss old-school Pascal strings (aka strings with a length field and a fixed allocation) sometimes. Pascal strings could automatically #[derive] a whole bunch of the Rust traits (Copy, Clone, Send, Sync, Eq, PartialEq, ...) that would help sidestep a whole bunch of ownership issues when you start throwing strings around in Rust. The downside would be that you would occasionally get a runtime panic!() if your strings overflowed. Sometimes, I can live with that. Embedded in particular would mostly prefer Pascal strings. I suspect that Rust is powerful enough to create a PString type like that and actually fit it into the language cleanly. The lifetime annotations may be the trickiest part (although--maybe not as everything is a fixed size).
- brundolf 6y ago
  > Pascal strings could automatically #[derive] a whole bunch of the Rust traits (Copy, Clone, Send, Sync, Eq, PartialEq, ...) Worth noting that the explicitness of #[derive] was a design decision; particularly when exposing a library API, it's good to have control over the set of interfaces you actually support, so that (for example) if one of them stops being derivable later you won't break people's code downstream
- selfhoster11 6y ago
  > The downside would be that you would occasionally get a runtime panic!() if your strings overflowed. VLQ/LEB128 would take care of encoding an arbitrary string size to avoid this issue.
cdcarter 6y ago
This is, as I understand it, how Symbols work in Ruby. They are prefixed with a colon, and are interned and immutable.
sedatk 6y ago
I'm glad they don't have it. Many "programming" identifiers, filenames, and whatnot already support Unicode. You'd be setting yourself up for failure because you forgot to update the type you used somewhere.
- alkonaut 6y ago
  But I want it to fail and I'm happy for it to fail then. If I write a utility that is about to read a multi gigabyte file in a json format I know has only ascii identifiers, into a dictionary, then it's silly that the dictionary has UTF-16 keys stored in an array on the heap, with each value stored on the heap as well, so second pointer away. Just because I'm using json or xml or something doesn't mean I'm parsing any json, or that I'm not happy for it to catch fire if I parse a file that has some non-ascii in it.

brundolf 6y ago

You can pretty much do this in Rust: let simple_str: &[u8] = b"hello world"; println!("{}", simple_str[6] as char); // 'w' Though I would advise against it in most cases, because even many "non-human" formats like XML and JSON do allow for Unicode characters

sedatk 6y ago
Filenames too.
- alkonaut 6y ago
  There is no problem making filenames that are bound ascii. Just because they can be non-ascii on most OS'es, doesn't mean they are (when I myself control all input - that's the key). I think it's the problem of generality here. If I make a game that has thousands of texture files I want to store in a lookup table and it saves me x ns on the lookup if those textures are in a dictionary with 1-byte characters vs 2-byte character keys, then I could just make sure my file names are ascii. So I have a collection of 2000 ascii file names. I don't care whether the rest of the files outside my game textures are, or could be, non-ascii.
  - Narishma 6y ago
    You shouldn't be using strings in that case anyway, especially if performance matters.

bsder 6y ago

I would say UTF-8, but I really do miss old-school Pascal strings (aka strings with a length field and a fixed allocation) sometimes. Pascal strings could automatically #[derive] a whole bunch of the Rust traits (Copy, Clone, Send, Sync, Eq, PartialEq, ...) that would help sidestep a whole bunch of ownership issues when you start throwing strings around in Rust. The downside would be that you would occasionally get a runtime panic!() if your strings overflowed. Sometimes, I can live with that. Embedded in particular would mostly prefer Pascal strings. I suspect that Rust is powerful enough to create a PString type like that and actually fit it into the language cleanly. The lifetime annotations may be the trickiest part (although--maybe not as everything is a fixed size).

brundolf 6y ago
> Pascal strings could automatically #[derive] a whole bunch of the Rust traits (Copy, Clone, Send, Sync, Eq, PartialEq, ...) Worth noting that the explicitness of #[derive] was a design decision; particularly when exposing a library API, it's good to have control over the set of interfaces you actually support, so that (for example) if one of them stops being derivable later you won't break people's code downstream
selfhoster11 6y ago
> The downside would be that you would occasionally get a runtime panic!() if your strings overflowed. VLQ/LEB128 would take care of encoding an arbitrary string size to avoid this issue.

cdcarter 6y ago

This is, as I understand it, how Symbols work in Ruby. They are prefixed with a colon, and are interned and immutable.

sedatk 6y ago

I'm glad they don't have it. Many "programming" identifiers, filenames, and whatnot already support Unicode. You'd be setting yourself up for failure because you forgot to update the type you used somewhere.

alkonaut 6y ago
But I want it to fail and I'm happy for it to fail then. If I write a utility that is about to read a multi gigabyte file in a json format I know has only ascii identifiers, into a dictionary, then it's silly that the dictionary has UTF-16 keys stored in an array on the heap, with each value stored on the heap as well, so second pointer away. Just because I'm using json or xml or something doesn't mean I'm parsing any json, or that I'm not happy for it to catch fire if I parse a file that has some non-ascii in it.