Is there a reason I'm not seeing why there isn't, say
proc `$`[T](x: ref T):string =
if x.isNil:
result = "nil"
else:
result = $x[]
Some danger I'm missing?
Recursive types lead to infinite loops.
that. which can be avoided by using a lookup table to avoid infinite recursion, but that belongs in a separate module. see https://github.com/nim-lang/Nim/pull/14043 for an alternative
that was exactly the method proposed in the inital proposal , but reading through its clear that $ will not be extended.
@zah points out that nim has issues with "default initialization of generic procs", possibly selecting the default when a user has provided an overload in a separate file, and the point is also strongly made that distinct types shouldn't have a $
a separate std/prettyprint module is blessed
repr is brilliant, but woe betide the poor devil who uses it on a Table
maybe something like
template pp(t:typed):string =
when compiles($x):
$x
elif compiles($x[]):
if x.isNil: "nil" else: $x[]
else:
x.repr
afaik the compiler already keeps track of which objcts can be cyclic and which not.
Compiler cannot keep track of cycles that appear at run time. Even simple linked list can start as linear and end up having a loop.
Compiler cannot keep track of cycles that appear at run time. Even simple linked list can start as linear and end up having a loop.
for a lot of objects it can be decided whether they are eable to form cycles or not at compile time. The orc memory management scheme uses this as an optimisation to only run the cycle collector on objects of types which can form cycles. On this topic there's also the acyclic pragma (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma).