Ack.
I'll take some time to try to come up with a more general abstraction that
might be worthy of being added to package iter.
That's hard just because I only have one use case, but I guess if no one
shares their use case (or makes concrete proposals) it's even harder.
Thanks!
Nuno
On Sun 23 Feb 2025, 19:45 Ian Lance Taylor, <i...@golang.org> wrote:
> On Sat, Feb 22, 2025 at 4:52 PM Nuno Cruces <ncru...@gmail.com> wrote:
> >
> > Is there any appetite to expose runtime.newcoro/coroswitch? They seem
> really useful beyond iter.Pull. They actually have the go:linkname
> handshake, but are then explicitly banned in the linker.
> >
> > I wanted to implement this "push like" interface with a "processor"
> function that accepts an iter.Seq and returns a result:
> >
> > func processor(seq iter.Seq[value]) result { ... }
> >
> > I've been cracking my head, and I'm convinced I can't with just
> iter.Seq/iter.Pull: I need a co/goroutine (and coroswitch, or channels).
> >
> > My implementation is here:
> https://github.com/ncruces/go-sqlite3/pull/229/files
> >
> > Maybe there's another higher level abstraction like iter.Pull we could
> build instead, but it's not apparent to me?
>
> I don't think we are likely to simply export newcoro and coroswitch,
> as they don't provide any functionality that we can't already get from
> goroutines, but are harder to use correctly. If someone can define a
> clean API that uses them based on channels, we could consider a
> proposal for that.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAM0U__-8XjZS1Cs2yfPzb20wRbiKLy4nPksTJ_%2B85eqxT%2BgdKw%40mail.gmail.com.
