> From: "Graydon Hoare" <[email protected]> > > Ok, the keyword stuff I'm not really interested in debating ad > infinitum, there just aren't _enough_ of them for this to be worth a > long discussion (and it's 5 chars vs. 6, seriously). The > abbreviations > in library code are a different matter. It's true that we have a > bunch > of abbreviated library names. Examples: > > vec (not Vector) > cmp (not Compare) > bitv (not BitVector) > dbg (not Debug) > dlist (not DoublyLinkedList or CircularList) > iter (not Iterable) > ptr (not Pointer) > rand::rng (not Random::Generator, say) > sys (not System) > rt (not Runtime) > > Are these sorts of abbreviated names actually posing a problem to > users?
I definitely like short keywords, and I don't have a problem with short names in the standard library, but I am a little worried about the precedent being set for Rust code in general. Take, for example, trans/base.rs in the Rust code base. The code uses abbreviations fairly aggressively, including ccx, bcx, icx, ty, ti, insn, ptr, t, incr, sess, among others. None of these are especially difficult to figure out, but the time it takes to get used to the code is non-zero. 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? _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
