This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-29
Channels
- # announcements (17)
- # aws (12)
- # babashka (27)
- # beginners (85)
- # bristol-clojurians (1)
- # calva (16)
- # cider (3)
- # clara (7)
- # clojure (80)
- # clojure-europe (13)
- # clojure-italy (19)
- # clojure-nl (2)
- # clojure-norway (6)
- # clojure-poland (1)
- # clojure-spec (31)
- # clojure-uk (61)
- # clojurescript (29)
- # core-async (10)
- # cursive (7)
- # data-science (1)
- # datomic (29)
- # docker (3)
- # fulcro (120)
- # graphql (16)
- # hugsql (2)
- # leiningen (17)
- # luminus (2)
- # off-topic (36)
- # other-languages (3)
- # pathom (13)
- # re-frame (12)
- # ring (2)
- # rum (1)
- # shadow-cljs (126)
- # tools-deps (56)
- # vscode (5)
Would it be ok to patch async/thread to return an async/promise-chan instead of a (chan 1) ?
arguably that would change behavior slightly when taking since currently it produces only a single message
what problem are you trying to solve?
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)
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