summaryrefslogtreecommitdiffstats
path: root/gencadr.txr
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2021-04-28 20:26:59 -0700
committerKaz Kylheku <kaz@kylheku.com>2021-04-28 20:26:59 -0700
commite0cc6c8c21b2442cd5b1f8f51afadca6f3649d70 (patch)
treeaf3f3e710be36d2a2a49dca0fcf3547341171fa3 /gencadr.txr
parent5410fe471273922ee53c579238e3d00bd28b6789 (diff)
downloadtxr-e0cc6c8c21b2442cd5b1f8f51afadca6f3649d70.tar.gz
txr-e0cc6c8c21b2442cd5b1f8f51afadca6f3649d70.tar.bz2
txr-e0cc6c8c21b2442cd5b1f8f51afadca6f3649d70.zip
lib: document gc problem related to seq-begin.
If seq-begin is used on an object that supports the iter-begin method, there is a gc problem. This does not seem worth fixing for the following reasons. 1. The seq-begin function is marked obsolescent. I removed its one and only internal use in the previous commit, so it won't be called unless application code uses it. 2. Objects supporting the iter-begin function are clearly developed as part of the new iteration protocol. It makes no sense to be newly developing such an object, along with new code which applies seq-begin to it. There is likely zero code in the wild which uses either of these mechanisms. * lib.c (seq_iter_get_oop, seq_iter_peek_oop, seq_iter_get_fast_oop, seq_iter_peek_fast_oop): Add comments documenting the issue.
Diffstat (limited to 'gencadr.txr')
0 files changed, 0 insertions, 0 deletions