Got it 👍
type O1 {.size: 1.} = object
a: uint64 # too huge for that size
assert O1(a: 9'u64).sizeof == 1
type O2 = object
a: uint64
assert O2(a: 9'u64).sizeof == 8
Run
?
Hi, at the moment, initialization of user defined numeric literals raises
ValueError through the use of parseInt, parseUint, which makes their unusable
with the new effects system.
For example:
from std/parseutils import parseUInt
type flg = distinct uint8
proc `'
It works:
template gen_str_in_ct_0: string =
when nimvm:
"sisix dev"
else:
"monkeys"
const a = gen_str_in_ct_0()
assert a == "sisix dev"
assert gen_str_in_ct_0() == "monkeys"
Run
But it fails:
template gen_str_i
> If you create a file config.nims and write a line like switch("import",
> "sugar"), you can write Nim code without writing import sugar under the
> directory containing that config.nims.
For me, the idea that module imports should be in the module itself is quite
obvious.
> Are you sure maki
Add **sugar** (or part of it ) to the system module!
* Some of the sweet features are not sugar per se, for example `dup` which
claims to be one of the [cool nim
features](https://nim-lang.org/blog/2020/04/03/version-120-released.html) and
be used a lot.
* Using of `->`, `=>`, `with` is goo
Hello nimmers,
I have created a [library](https://github.com/sumatoshi/w8crc) for calculating
crc's and encountered [some strange
behavior](https://github.com/sumatoshi/w8crc/blob/facf4f2956f5b5216d78dd6978377069dcd9c1ed/src/w8crc/algobitwise.nim#L187)
with const computations in the templates (
