Duplicated(?) pseudo-constructor for Channels

[DmitriyZaitsev]

There are two pseudo-constructors for Channels:

1. for unbuffered channel:

public fun <E> Channel(): Channel<E> = RendezvousChannel<E>()

2. for channels with buffer capacity:

public fun <E> Channel(capacity: Int): Channel<E> =
    when (capacity) {
        0 -> RendezvousChannel() // <-- dupication
        UNLIMITED -> LinkedListChannel()
        CONFLATED -> ConflatedChannel()
        else -> ArrayChannel(capacity)
    }

The second constructor completely includes the first one if capacity is 0.
It's KDoc says:

Creates a channel with the specified buffer capacity (or without a buffer by default).

So, my suggestion is to remove that first pseudo-constructor and add default parameter to the second like below. This won't affect existing API from user's perspective, and we'll get beautiful kotlinized factory method:

public fun <E> Channel(capacity: Int = UNBUFFERED /* default == 0 */): Channel<E> =
    when (capacity) {
        UNBUFFERED -> RendezvousChannel()
        UNLIMITED -> LinkedListChannel()
        CONFLATED -> ConflatedChannel()
        else -> ArrayChannel(capacity)
    }

I can send a PR with this change.

[elizarov]

The first pseudo-constructor was added for the purpose of ahead-of-time dead code elimination (if you are using only rendezvous channels in your code, it should be possible to statically provide this fact and remove all other implementations from your code). We're not there yet, but that is a tentative goal. Anyway, for 0.xxx release we are trying not to remove anything to keep binary compatibility for people who rely on kotlinx.coroutines library in their projects.

We will review all the methods for 1.x release and remove all the deprecated method and all the overloads like this if we find them unnecessary.

[DmitriyZaitsev]

Thanks @elizarov!
Does this mean the first pseudo-constructor isn't found unnecessary and isn't going to be deprecated for now?
E.g. if I said "deprecate" for 0.xx instead of "remove", would you consider adding default param to the second pseudo-constructor reasonable?

[elizarov]

Adding/removing default parameters is non-binary compatible change in Kotlin. We might deprecate anything before 1.0 release of kotlinx.coroutines, but we are trying not to remove anything to keep previously compiled code operational.