Skip to content

Numeric literals with spaces as delimeters #42

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
gopherbot opened this issue Nov 11, 2009 · 10 comments
Closed

Numeric literals with spaces as delimeters #42

gopherbot opened this issue Nov 11, 2009 · 10 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language

Comments

@gopherbot
Copy link
Contributor

by Serge.Sitnikov:

Please could you change the grammar to accept following numeric literals:

const
(
  nanoseconds_per_second = 1 000 000 000;
  packed_primes = 0x 02 03 05 07 0B 0D 11 13;
  epsilon = 0.000 001;
)
@agl
Copy link
Contributor

agl commented Nov 11, 2009

Comment 1:

Your request isn't unreasonable, but we are very conservative with language features.

Labels changed: added language-change.

@rsc
Copy link
Contributor

rsc commented Nov 11, 2009

Comment 2:

Status changed to Thinking.

@gopherbot
Copy link
Contributor Author

Comment 3 by michael.jones:

You could implement Serge's good idea using the existing special symbol "_" 
(Underscore) which Go uses to say "present but missing" in other contexts. This 
would make parsing effortless.
const
(
  nanoseconds_per_second = 1_000_000_000;
  packed_primes = 0x_02_03_05_07_0B_0D_11_13;
  epsilon = 0.000_001;
)
It shares most of the benefit, avoids the issue of a spaced-out hexadecimal literal 
with a segment beginning with [a-fA-f] seeming like a non-number, and adds a bit 
of Ada to Go.

@gopherbot
Copy link
Contributor Author

Comment 4 by joseph.stewart:

Any consideration for Erlang style numeric constants?
They're in the format
BASE_IN_DECIMAL # NUMBER_IN_BASE_WITH_POSSIBLE_UNDERSCORES
examples:
2#111 = 7 dec
16#ff = 255 decimal
36#zzz = 46655 decimal

@gopherbot
Copy link
Contributor Author

Comment 5 by Serge.Sitnikov:

Agree with Michael. Underscores not so intuitive and clean as spaces, but they will 
leave a room for future language extensions, for something like composite space-
separated set literals.

@gopherbot
Copy link
Contributor Author

Comment 6 by netchv:

Really Erlang copies Ada approach with small change (Ada #p#n -> Erlang p#n). I also
vote for this - it gives much readability without any syntax conflict.
Also I vote for discarding treating "0..." as octal (in #145).
(To justify myself: this of course seems like bikeshed, but IMHO it really influes
the readability)

@gopherbot
Copy link
Contributor Author

Comment 7 by notan.kdev:

Underlines are used in other languages.  
1_000_000_000 is much more readable than 1000000000
ADA allows it.
the IEC61131-3 Languages for PLC programming to.

@jimmyfrasche
Copy link
Member

Comment 8:

I had never considered spaces in numeric literals before but I like it because it
follows the current convention of lexical concatenation of string literals, such as
"A" " string"

@gopherbot
Copy link
Contributor Author

Comment 9 by JQBalter:

"Your request isn't unreasonable, but we are very conservative with language features."
What a ridiculous comment. How about banning multiple spaces -- or even all
unnecessary spaces, in programs because allowing them isn't "conservative"? What
about unicode identifiers -- *that* isn't conservative!
Allowing underscores within numeric constants is a small upwards-compatible change
localized to the lexer -- it barely deserves to be called a "feature".

@robpike
Copy link
Contributor

robpike commented Nov 21, 2009

Comment 10:

Status changed to WontFix.

@bradfitz bradfitz added the LanguageChange Suggested changes to the Go language label Dec 17, 2014
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language
Projects
None yet
Development

No branches or pull requests

6 participants