things rust shipped without

[graydon2]

Well-known things I'm very proud that rust shipped 1.0 without:

• null pointers
  
• array overruns
  
• data races
  
• wild pointers
  
• uninitialized, yet addressable memory
  
• unions that allow access to the wrong field
  

Less-well-known things I'm very proud that rust shipped 1.0 without:

• a shared root namespace
  
• variables with runtime "before main" static initialization (the .ctors section)
  
• a compilation model that relies on textual inclusion (#include) or textual elision (#ifdef)
  
• a compilation model that relies on the order of declarations (possible caveat: macros)
  
• accidental identifier capture in macros
  
• random-access strings
  
• UTF-16 or UCS-2 support anywhere outside windows API compatibility routines
  
• signed character types
  
• (hah! vertical tab escapes (as recently discussed) along with the escapes for bell and form-feed)
  
• "accidental octal" from leading zeroes
  
• goto (not even as a reserved word)
  
• dangling else (or misgrouped control structure bodies of any sort)
  
• case fallthrough
  
• a == operator you can easily typo as = and still compile
  
• a === operator, or any set of easily-confused equality operators
  
• silent coercions between boolean and anything else
  
• silent coercions between enums and integers
  
• silent arithmetic coercions, promotions
  
• implementation-dependent sign for the result of % with negative dividend
  
• bitwise operators with lower precedence than comparison operators
  
• auto-increment operators
  
• a poor-quality default hash function
  
• pointer-heavy default containers
  

Next time you're in a conversation about language design and someone sighs, shakes their head and tells you that sad legacy design choices are just the burden of the past and we're helpless to avoid repeating them, try to remember that this is not so.

Comments

[squirrelitude]

It all sounds so wonderful! :-D

...what's wrong with random-access strings? Unless I'm thinking of something else.

[graydon2]

It depends what you want random access to. Most people think they want random access to "an element" of "a string" as "a character". But in unicode, most meaningful algorithms operate on graphemes or linguistic units like words, not characters -- a grapheme might be a cluster of several combining characters -- and conversely most encodings you're going to read from streams don't put single codepoints at randomly-accessible locations (neither UTF-8 nor UTF-16 let you grab a codepoint by index in constant time).

So ... if you want to convert everything to (say) an array of UCS-4 codepoints on every input, you can random-access the string "as characters", but then you've spent a bunch of time decoding and normalizing and you've still probably only got non-linguistically-useful units, and you need to re-convert on the way back out. Some programming languages do this by default in order to preserve "random access strings", but Rust does not, and this is intentional. Rust's default strings are UTF-8. This is the form you need for I/O 99% of the time, is memory-dense, interoperates well with C strings (UTF-8 is very well designed), but it supports sequential access only.

You can convert it "for free" to a byte array -- with random access -- if you want to do byte-level operations on it, but then it's not a string anymore. And you can convert it at some cost to an array of char (UCS-4) if you really want to do random character-based algorithms. We're not trying to be obtuse! Just pick the right default.

[squirrelitude]

Interesting... right, for string blitting operations I want UTF-8, and for string manipulation I (because of what I work on) want char arrays. The latter is more visible, but the former is perhaps the more important case for performance, depending on what you're doing. Certainly if I were doing linguistics work, UTF-8 would be just fine.

I imagine this was a rather controversial one. :-P

[graydon2]

No, actually we hardly fought over it at all. I think most people in the systems-language space are comfortable with UTF-8. It interoperates very well with C and C++ libraries -- basically anything expecting ASCII will see "ASCII plus some high bytes", which means everything from strlen to regcomp still "works" even if not unicode-aware. It works on the ASCII subset and ignores the rest.

A small number of people complain and we point out that all it means is you have to make one extra call in order to unpack-to-char-array if you want a char array. That, combined with the compatibility and efficiency around I/O, seems to quiet most opposition.