Skip to content

Add support for hyphens in identifiers #4304

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
paulmillr opened this issue Dec 28, 2012 · 11 comments
Closed

Add support for hyphens in identifiers #4304

paulmillr opened this issue Dec 28, 2012 · 11 comments

Comments

@paulmillr
Copy link

let (from_child, to_child) = DuplexStream();
let some_long_quite_sort_of_stuff = "stuff";
let (from-child, to-child) = DuplexStream();
let some-long-quite-sort-of-stuff = "stuff";

Hyphens are more readable than underscores and do not require pressing shift every time. Which will be annoying if you use an underscore_case language. Try writing long word from first example and from the second.

Underscores have been around since forever, but ask yourself: are modern non-engineers aware about the character? The answer is: nope. No one gives a shit about underscores except of IT guys.

Languages that use hyphens successfully: Clojure (& lisps), LiveScript (take a look at examples) etc.

Thoughts?

@catamorphism
Copy link
Contributor

This would cause a parsing ambiguity: does let x = y-z; mean "bind x to the result of subtracting z from y", or "bind x to the value of the identifier y-z"? It could be resolved with enough lookahead, but it's not something that's simple to handle right now.

@paulmillr
Copy link
Author

@catamorphism nope. just parse y-z as identifier, prohibiting subtracting without spaces around (y - z) which is a good code style anyway.

@catamorphism
Copy link
Contributor

I think code style is a personal issue. We try as best as possible not to impose one style on everyone, and to talk about our preferences as just that, rather than objective truths.

@brendanzab
Copy link
Member

Underscores have been around since forever, but ask yourself: are modern non-engineers aware about the character? The answer is: nope. No one gives a shit about underscores except of IT guys.

Ruby devs might disagree.

Clojure (& lisps)

Lisp and its descendants use prefixed s-expressions, so there are no ambiguities or readability issues.

Personally I'd stick with C on this. The underscore style is also deeply entrenched in the 'rustic' coding style, so it's probably better you get used to it now if you want to be working with other devs.

I've mostly used camelCase in the past so I really didn't take to the underscore style at first, but after using Rust for several months it has definitely grown on me. Embrace the underscore!

@paulmillr
Copy link
Author

Good article by rubyist: http://devblog.avdi.org/2012/05/15/underscores-are-stupid/, he agrees with the point. And rubyists are it guys anyway.

By background is python, ruby and javascript. Underscore_case is idiomatic in py and rb and it’s certainly better than camelCaseStuffCrapMehHeyLolz, but still not as good as hyphens.

underscore style is also deeply entrenched in the 'rustic' coding style

Yea, but rust is not as stable and mature as python, ruby or c. It’s not late to innovate with stuff like this.

I know devs can be conservative when it comes to syntax, but just think about objective advantages of using hyphen-case. Not requiring you to press shift all the time etc.

@steveklabnik
Copy link
Member

I will say that I'm trying to introduce Rust to Rubyists specifically, and kinda making a big deal that a lot of the syntax is very similar, as a gateway drug.

I won't cry if -s are chosen instead, but _s sure do make Rust comfy at the moment.

@catamorphism
Copy link
Contributor

@paulmillr: Not everyone who works on Rust is a guy, so please refrain from using gendered language when talking about Rust programmers (or any programmers).

There are no "objective advantages" of any language syntax. Sorry. It's all about feelings and subjective mental states.

Please re-read the "Conduct" section of https://github.com/mozilla/rust/wiki/Note-development-policy

@komiga
Copy link

komiga commented Dec 28, 2012

Hyphens are more readable than underscores […].

Ah, the zenith of incorrectness. We meet again.

@wilmoore
Copy link

...Not everyone who works on Rust is a guy, so please refrain from using gendered language when talking about Rust programmers (or any programmers).

@catamorphism: good call.

support for hyphens in identifiers...Thoughts?

@paulmillr Yes...definitely yes.

@graydon
Copy link
Contributor

graydon commented Dec 29, 2012

While I am a sympathetic, card carrying member of the Ancient Order Of Strange Old Lisp People, as are several Rust developers, Rust is lexically Not A Lisp in several different capacities, and not about to become one. We draw our identifier rule from Python, and more-recent adaptations of the C family lexeme rules to unicode. In particular, the XID_Start / XID_Continue pair. 'U+005F LOW LINE' is in class XID_Continue, whereas 'U+002D HYPHEN-MINUS' is not.

So no. Closing this on the basis that it's more or less arbitrary and we've already made this decision. At length.

@graydon graydon closed this as completed Dec 29, 2012
@rinarakaki
Copy link

While I agree that any sequence of characters without a white space would be lexed as an identifier—like in Haskell, the most anticipated and straightforward path to restoring hyphens ‘-‘ U+002D in identifiers is that we are going to use minuses ‘−’ U+2212 as minuses (of punctuations) and hyphens as hyphens.

Though the team are going to have officially to provide some input support or guidelines either at editor level (VSCode, Emacs) or keyboard level (MacOS, Windows).

The potential ergonomic gain by this would be intense when Rust becomes more used in

  • Web UI development
    e.g. <my-component></my-component>
  • Proof assistant development
    e.g. 2-category, or even (∞, 1)-category

RalfJung pushed a commit to RalfJung/rust that referenced this issue May 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants