> That test is also part of our test suite and is so complex that it doesn't
> run on 32 bits, nor in C++
I was not aware that it is in test suite. But I was aware that it does not
compile with C++, and that nimsuggest has big problems with it. Will try to
investigate which problems with 32 bit may occur, that may be a bug of mine.
gintro with destructors, that seems to be nearly impossible. We discussed that
years ago when destructors became available for Nim, mratsim was involved. The
main problem is, that we can pass objects to gtk lib, and can GET BACK the same
object later. For example a widget in a grid container -- we create a widget,
put it into grid container, forget it, and get it back later, maybe put it into
another container then. That seems to be really a hard problem, and people will
expect that this works. Maybe we could disallow it, but it is a serious
restriction. I think that is not only a restriction for gtk, maybe for libs
like CGAL or BOOST too, where we may intent to store objects in data structures
of that lib, for example edges and vertices in a spatial triangulation data
structure. (Maybe there are solutions, we may not use refs, but id numbers for
access.)
> I was surprised that GC_ref() compiles with --gc:arc
type
O = ref object
i: int
proc main =
var
o = O(i: 7)
GC_ref(o)
echo o.i
main()
Run
Of course gc:arc is great, I like the deterministic memory management. For
native Nim libs it should work fine.
