Closed Kuniwak closed 3 months ago
Are there any possible drawbacks to implementing buildEither
(changes/breakage to the existing API)? From a surface look I can't see any - so with that in mind I would be in favor of adding support for this. I am happy to review and test the PR.
Are there any possible drawbacks to implementing
buildEither
(changes/breakage to the existing API)? From a surface look, I can't see any
I agree. Based on my reading of SE-0289, adding the buildEither
method seems to be a purely additive change because it only increases the syntax available within the resultBuilder
. The SelectHandler
generated by the existing syntax remains unchanged. Therefore, I believe the behavior of select
statements that did not previously cause compilation errors will not be affected by the addition of the buildEither
method.
I sent a pull request about it at #10.
Hello,
I would like to discuss the possibility of accepting a PR to add the
buildEither
method toSelectCollector
.The use case I am about to explain is quite specialized, and I acknowledge that almost no one else using this library, except for me, may ever need this functionality.
I am a developer trying to create a CSP library in Swift similar to JCSP. JCSP is a library that implements some CSP functionalities in Java. One of the features of CSP is external choice, which allows the selection of channels that can either send or receive messages. I plan to use
select
for selecting channels that can send or receive messages. However, in implementing this external choice, using Async-Channel gives too much flexibility, making verification difficult. Therefore, I plan to publish the following code with restrictions to reduce this flexibility:This code encounters an error because there is a switch statement inside the
select
, andSelectCollector
does not have thebuildEither
method. Therefore, would it be possible to addbuildEither
toSelectCollector
?If you are open to this addition, I will prepare a PR. I would appreciate your feedback on this matter.