core-async

mpenet 2020-01-29T16:10:38.300300Z

Would it be ok to patch async/thread to return an async/promise-chan instead of a (chan 1) ?

mpenet 2020-01-29T16:11:10.300900Z

arguably that would change behavior slightly when taking since currently it produces only a single message

ghadi 2020-01-29T16:12:54.301200Z

but why?

mpenet 2020-01-29T16:17:03.301400Z

why not 🙂

mpenet 2020-01-29T16:17:15.301700Z

for one I think that might be slightly more efficient/lightweight

mpenet 2020-01-29T16:17:44.302200Z

I suspect if it was written today it might be using promise-chan, don't you think?

alexmiller 2020-01-29T16:22:50.302500Z

what problem are you trying to solve?

mpenet 2020-01-29T16:23:46.302900Z

none I was merely wondering while reading the source

2020-01-29T19:46:02.311100Z

There might be a slight difference in behavior somewhere since if thread returns nil the channel just closes, but a promise-chan with nil val has a count of 1 (just from reading the source, not sure about the implications)

2020-01-29T19:46:24.311800Z

If you where making a change there (which meh) a promise-chan still isn't the best thing to return, because a promise-chan is still both a read port and a write port, and I think the best thing for go blocks to return is something that is just a read port. But I do think there are arguments to be made for the uniformity of just channels without the read/write port splitting