This is an interesting approach. I would have following question/feedback to the design:
1. In view of the intent to broadcast a non empty value to all receivers of a channel, my intuition would be that the receivers should receive the value only once. What was the rational behind the continuing receiving of the "sticky" value from a logical point of view? Maybe a broadcast send could be initiated with ch <* x. The receiving goroutine would receive the value and would park until the channel is signaled to be ready for another value, either a sticky or a non sticky one. This could eliminate the application logic part of versioning the receives and unnecessary loops on that. 2. The block until full receive x <| ch seems to be a means to synchronize on goroutine termination in a select thus allowing to implement a timeout. However, one would need to know the number of goroutines to synchronize for beforehand - which seems not to be a universal case. The intent to have a timeout on Wait could simply be achieved by Wait() replicating the context Done() logic. Hannes Jason E. Aten schrieb am Donnerstag, 30. Oktober 2025 um 08:48:38 UTC+1: If you ever wished for + better Deterministic Simulation Testing (DST) support, or + that channels could replace Condition Variables, or for + a sync.WaitGroup alternative that could be interrupted by a timeout, or that + channel close could be idempotent and broadcast a non-zero value, then I invite you to experiment with my superset-of-Go experiment, Pont. https://github.com/glycerine/pont Feedback welcome -- post an issue on the repo. Jason -- 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/26b86467-3bea-4aaf-8e81-8e5239fb8827n%40googlegroups.com.
