On Tuesday, November 4, 2025 at 5:20:12 AM UTC Will Faught wrote: I had in mind a goroutine that receives commands for channel-like operations and implements them itself. So it would have a list to store the sent values, a sticky value variable, lists of receive commands (containing the channel to send a value back on), and lists of receive-full commands (containing the channel to send the values back on). It would loop on selecting for incoming commands, and behave accordingly. It’s not as efficient as having the behavior built in, no doubt, but probably simpler to implement.
Nice. I have been thinking along similar lines. The difficulty is one of implementation. It's such a large departure from the existing code that I would not know how to even begin to make it work. Current channel ops never do that behavior, which would involve a) starting and/or resuming a goroutine; b) blocking on it's finish/yielding; and c) then resuming after a "3rd party" goroutine that is not otherwise involved in blocking on a channel. It might be easier to associate one channel to "monitor" or proxy another channel, and to implicitly have the monitor channel interpose when the monitored channel was considered for a channel op. (I am thinking of how the P formal modeling language uses monitors to check correctness; https://p-org.github.io/P/whatisP/ ) This is also more in line with my select discipline -- where in production I never allow just a single channel in a select and never use range over channel. To be able to cancel any operation, there always must be at least two channels used together. Experimenting with explicit support for that convention might be an interesting research direction. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/72ebc905-1565-47b0-a94d-cf5b1e2270d5n%40googlegroups.com.
