Chapel: Feature request for integer-literal separators

[BryantLam]

Feature Request. Could I get an integer-literal separator?

C++14 uses the quote character.

Optional single quotes(') may be inserted between the digits as a separator. They are ignored by the compiler. ... unsigned long long l2 = 18'446'744'073'709'550'592llu; // C++14

Rust uses underscores.

• All number literals allow _ as a visual separator: 1_234.0E+18f64

Swift also uses underscores.

[lydia-duncan]

Is the intention behind this something like the comma in English numbers? i.e. 1,200 == 1'200 in C++?

[BryantLam]

Yep. It's basically just to break up long literals to be more readable.

[daviditen]

I think underscores to separate groups of three digits would make the most sense for this. I don't think we can use commas because it would be ambiguous with tuples and function arguments. I don't think we can use quotes like c++14 because it would be ambiguous with single-quoted strings.

I think the separators should only be allowed after every third digit from the right. These should be allowed:

1_234
12_345

These should not be allowed:

_123
123_

I think supporting this for decimal integer literals makes sense and would be useful. It may also be useful for the other supported integer literal bases (binary, octal, hexadecimal) and for floating point literals.

[benharsh]

I'm not sure about only allowing the underscore after three digits. At a glance, I'm not seeing other languages with that restriction.

A motivating example might be a phone number:

This python PEP has links to this kind of feature in other languages: https://www.python.org/dev/peps/pep-0515/#prior-art

Edit: The point of the phone number example being that the literal may not represent a normal number, and could just be a way of representing some other information (e.g. some configuration encoding). I don't actually think that phone number literals will be used 😄

[daviditen]

I'm not sure about only allowing the underscore after three digits. At a glance, I'm not seeing other languages with that restriction.

OK, removing that restriction sounds fine to me.

[bradcray]

Should non-decimal (binary, hex, octal) literals support these as well? My thinking is yes, particularly if we're not limiting it to marking thousands places. For example, I could imagine it being useful to separate binary literals into chunks of 8 bits, hex to chunks of 4 or 8 hex symbols, etc. (With a quick glance, it appears the Python PEP suggests they went that route as well?).

[edit: Oh, and floats as well?]

[daviditen]

Should non-decimal (binary, hex, octal) literals support these as well? [edit: Oh, and floats as well?]

I also think yes.

[mppf]

and floating point values!

[dmk42]

I agree with removing the three-digit restriction. Although western countries tend to group three digits at a time, the most important powers of 10 in Japan are multiples of four.

[daviditen]

Closed with PR #11464.

[ronawho]

Do we want/expect this to work for config vars and/or string->int casts?

config const i = 1_000;
writeln(i);

./configUnderscore --i=1_000
uncaught IllegalArgumentError: bad cast from string '1_000' to int(64)
  $CHPL_HOME/modules/internal/ChapelBase.chpl:1073: thrown here
  $CHPL_HOME/modules/internal/ChapelBase.chpl:1079: uncaught here

const i = "1_000":int;
writeln(i);

./castUnderscore
uncaught IllegalArgumentError: bad cast from string '1_000' to int(64)
  castUnderscore.chpl:1: thrown here
  castUnderscore.chpl:1: uncaught here

[bradcray]

That's a good question. I think it's worth opening a design issue to consider this question.

[bradcray]

(note that supporting the string->int case should give us the config case automatically).

[ronawho]

That's a good question. I think it's worth opening a design issue to consider this question.

https://github.com/chapel-lang/chapel/issues/11756