I wish it were `launch(CommonPool.copy(parent = job)) {}` Starting to think that the `+` was too cry...

# coroutines

[voddan]

I wish it were launch(CommonPool.copy(parent = job)) {}
Starting to think that the + was too cryptic to begin with

[Jonathan]

I personally find CommonPool.copy(parent = job) even more cryptic.

Anyway, you can do launch(CommonPool, parent = job) {}

[voddan]

.copy(a=b) is the same syntax as for data classes. What is cryptic about it?

[Jonathan]

When you do copy with a data class, the class already have the property you want to change. CommonPool doesn't have any parent. It's only a thread dispatcher.

[Jonathan]

x.copy(a=b) usually return an instance of the same type of x. Here it wouldn't be possible and wouldn't make sense as thread dispatcher never contains Job element. with + you explicitly build a new object (A context) which contains "the dispatcher + the job"

[deviant]

i love + and how Elements combined into one context

[voddan]

Correct me if I am wrong, but CommonPool is a context with undefined parent. So conceptually there is no difference between + and copy

[voddan]

The problem with + for forming contexts is that it is not explicit what part of context is changing. For example context + job replaces the current parent with job, but it is implicit. The launch(context, parent = job) is an attempt to fix that issue. In a sense, context.copy(parent = job) is + with explicit naming

[voddan]

The advantage of having context.copy(...) is that it is defined once for all context, not in every builder like launch. Plus it can be generalized to include other parameters like context.copy(name = ":)")

[Jonathan]

CommonPool is not semantically a Context and this is my point. CommonPool is a `CoroutineDispatcher`which is an Element of Context. with + you explicitly create a new Context by assembling elements. Of course Element implements Context and this may be confusing. But for me it is quite natural to create a context with form like "dispatcher + job + whatever".

[Jonathan]

And + is already "defined once for all context". As you said, there is conceptually no difference between the + and the copy you propose. Except that a good x.copy() function (IMO) should always return an instance of the same type than x (like it is the case for data classes). And this is is not possible with a CoroutineDispatcher. Because instances of `CoroutineDispatcher`would never contains any parent Job.

[voddan]

@elizarov has Context.copy(parent, name, ...) been on the table ?

[deviant]

for me it looks like java api. not kotlin

[elizarov]

@voddan Let’s open issue with this enhancement in kotlinx.coroutines issue tracker and move discussion there.

[voddan]

https://github.com/Kotlin/kotlinx.coroutines/issues/264