I do use linear update version time to time when I do know there's no worry about leaking reference and need some easy boost of performance. But I agree that their name may be making them easier to be misused.  Besides incorrectly assuming the updated structure is mutated and not using return value, it is also tricky to ensure no reference to it is leaked---capturing via continuation isn't obvious.

It may be too late, having srfi-1 and srfi-113, but if possible, giving them more distinguishing names may be a good idea.  We don't want to introduce another convention hastily though; we could exclude linear update apis from srfi-146, and then separately discuss a consistent convention that would also augument srfi-1 and srfi-113.


On Tue, May 2, 2017 at 3:33 PM, Per Bothner <xxxxxx@bothner.com> wrote:
On 05/02/2017 03:43 PM, John Cowan wrote:

On Tue, May 2, 2017 at 6:15 PM, Per Bothner <xxxxxx@bothner.com <mailto:xxxxxx@bothner.com>> wrote:

    "Linear update" APIs make me very uncomfortable and nervous.


SRFI 1 and SRFI 103 (sets) already provide them.

Which is no reason to repeat that mistake.
--
        --Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/