diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2021-04-28 20:26:59 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2021-04-28 20:26:59 -0700 |
commit | e0cc6c8c21b2442cd5b1f8f51afadca6f3649d70 (patch) | |
tree | af3f3e710be36d2a2a49dca0fcf3547341171fa3 /tests/010/strstream.expected | |
parent | 5410fe471273922ee53c579238e3d00bd28b6789 (diff) | |
download | txr-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 'tests/010/strstream.expected')
0 files changed, 0 insertions, 0 deletions