RFC: represent all litterals as string

[timotheecour]

literals-as-strings

this was discussed in forum recently (EDIT: not sure how to find it D20200425T182934; EDIT: https://irclogs.nim-lang.org/02-04-2020.html#12:45:32); the idea is to make the parser emit litterals (eg 123, 123'u8, 23.4, -34 etc) as strings instead of doing the parsing there; and the parsing would be deferred to semcheck phase

benefits

• BigInt support (eg https://irclogs.nim-lang.org/02-04-2020.html#12:37:04)
• remove edge case where T.low can't be used as a litteral for signed types T, eg -128'i8, see https://github.com/timotheecour/Nim/issues/125
• repr (and runnableExamples rendering etc) would preserve original source code formatting (refs https://github.com/nim-lang/Nim/issues/8871); it'd also make it easier for nimpretty and nim doc

alternatives considered

• tkBigNum proposed here https://irclogs.nim-lang.org/02-04-2020.html#12:45:32 is less useful, doesn't help with other things, eg keeping source code representation, or floating point litterals

links

D20200425T180920

• related PR: [WIP] Adding support for user-defined number suffixes by JohnAD · Pull Request #17020 · nim-lang/Nim

info

• https://irclogs.nim-lang.org/02-04-2020.html#12:39:02 fwiw nkIntLit is used in the compiler 131 times, it's quite a change

more discussion

(around https://irclogs.nim-lang.org/02-04-2020.html#12:31:25)

• strings really seem like the most sane option here.
• nimpretty, arbitrarily big custom int literals, fixing the -128 issue
• in the macro system we already have an 'intVal' accessor, we can do the parsing in there
• as 1000 loses information over 1_000'i32
• parsing them in the lexer is a hack really, nimpretty needs to extract the numbers back from the original source code

open questions

• how to deal with backward compatibility
• how to deal with existing macros

[timotheecour]

had some new ideas after looking at https://forum.nim-lang.org/t/6310#38884, moving discussion to https://github.com/nim-lang/RFCs/issues/228