[rust-dev] Bikeshed proposal to simplify syntax

Patrick Walton pwalton at mozilla.com
Tue Jul 17 14:39:37 PDT 2012


On 7/17/12 2:23 PM, Elliott Slaughter wrote:
> Now imagine that third-party Rust libraries follow this example. Now
> I have to learn abbreviations for every library I use in my
> application. If for any reason I need to modify a third party library
> for my own purposes, I'll need to learn its internal abbreviations as
> well.
>
> Should we really be using short name everywhere? And if not, how do
> we encourage people to use readable names, given the example we are
> providing in the standard library?

Agreed. I personally prefer longer, unabbreviated names (and camel-cased 
types) in user code for this reason. Keywords are a small fixed set of 
things that all users of the language must know, while user code 
contains an unbounded number of abbreviations in the limit. See resolve3 
for an example of this (although perhaps my names are *too* long there...)

In general I'm not a big fan of Unix-command-line-style abbreviation. It 
works and is elegant when programs are kept very small, but as programs 
grow larger and larger programmers have to page in and out abbreviations 
too often for easy reading. Functions like CreateOrRecycleThebesLayer() 
and UpdateDisplayItemDataForFrame() in Gecko may be lengthy, but they 
sure make digging through MXR easier.

Unix was forced to abbreviate for the 6 character limit, but that 
doesn't exist anymore. In fact, modern Plan 9 code doesn't abbreviate 
nearly as often as we do; they just pick short names. Take esc.c (just 
as an example) from Go:

http://code.google.com/p/go/source/browse/src/cmd/gc/esc.c

We have escapes(), visit(), visitcodelist(), visitcode(), analyze(), 
escfunc(), escloopdepthlist(), escloopdepth(), esclist(), esc(), 
escassign(), esccall(), escflows(), escflood(), escwalk(), and esctag(). 
If we assume that the "esc" prefix is just C namespacing, then the only 
*abbreviation* there is "func". The rest are just short names. The 
resulting code reads much nicer than the Rust code in our compiler. 
Short names are fine and read well; abbreviations don't.

(In fact, I prefer unabbreviated keywords in general; I'd prefer 
"return", "module", and "match", but I'm happy to yield to the tastes of 
the community and BDFL here, since I feel that abbreviated keywords have 
a much smaller cost than abbreviated user code.)

Patrick


More information about the Rust-dev mailing list