Also, I personally believe that camel case for type names would be a net loss; the underscore separates the words nicely, and I think it's pretty clear from the syntax what is and is not a type name (in my extremely limited experience).
Back in the day, I used ObjectPascal, where we used camelcase for everything: function names, variables, types. Borland set an early precedent by prefixing many class types with the letter T, thus to visually distinguish them from other things: So you had TWindow, TButton, etc. This system makes sense when you see it in practice:
function GetParent(Window: TWindow): TWindow;
begin
...
Ruby has some syntactic oddities I like precisely because they provide visual classification: "@" for instance variables and "@@" for class variables:
class User
@@max_name_length = 32
def initialize(name)
raise "Error" if name.length > @@max_name_length
@name = name
end
end
fn save(user: user) {
...
}
let foo = user.new();
let foo = User.new();I'm sure camel casing will be controversial, but it makes sense given that Rust's primary audience is Mozilla, where camel case is the enshrined naming convention for its C++, Java, and JavaScript code. Python's standard library is an ugly example of what happens when the language community can't settle on one convention.
Also, I wonder why 21st century languages still use "&&" and "||" operators. Python's "and" and "or" operators are easier to read (for English speakers) and type. They don't require shifting of distant keys. "and" has two home row characters. "or" has fewer keystrokes than "||". :)