Add Task.isCurrent

[KaQuMiQ]

Add extension to Task allowing to check if it is currently running task.

[ktoso]

This would need a swift evolution proposal: https://github.com/apple/swift-evolution

It's not wrong per se, but makes me wonder about the usefulness of this check.
Can you explain more why you'd need such method?

[ktoso]

Needs Swift Evolution proposal

[KaQuMiQ]

Sure! The main use case of this is to allow clearing / cancelling tasks which are spawned to produce a side effect on an object which keeps track of multiple tasks. Tasks cannot have a reference to itself (nor any identifier unless you explicitly create one on the side) in order to identify themselves i.e within a callback to the object managing tasks. So i.e. if you have an object which spawns a task for mutation of itself while tracking spawned tasks and one of them finishes this allows to identify which one it was without any additional work. This is extremely useful in case where you chain multiple tasks. In that case you can track reference only to the latest one and use that reference for spawning next (exchange current with new one and wait for current inside new one). In that case if you want to clear the task on callback you know if latest scheduled is the one which is executing callback. I am already using this implementation: https://gist.github.com/KaQuMiQ/a3a73bfd7ff4b41c7d231a1ce1555bde for this purpose. It helps simplifying multiple tasks management by eliminating additional unnecessary identifiers.

[ktoso]

Hmmm... this sounds somewhat suspicious if I'm to be honest. A Task is Hashable/Equatable so you could store and "remove this one" if you do pass around unstructured Task, and the notion of chaining tasks also seems suspicious. With async/await the "chaining" as you'd normally do with Futures is done using async/await, and not chaining one task to another.

I would suggest we take this idea to the forums: https://forums.swift.org where you can take a stab at a Swift Evolution style writeup why this is necessary and we could evaluate the specific use-cases. Right now I'm a bit concerned that code patterns that we don't want to encourage made you reach for this.

Thanks in advance!

[KaQuMiQ]

A Task is Hashable/Equatable so you could store and "remove this one" if you do pass around unstructured Task

Yes, but when you spawn a Task it does not have an access to reference to itself. Having a proxy access would require additional dedicated synchronization or could lead to grabbing invalid reference to different task when gathering exclusive access to the reference again after task was spawned.

let spawned: Task = .detached {
  // can't get reference to spawned, doing it from outside might return different task after synchronizing access again
}

the notion of chaining tasks also seems suspicious. With async/await the "chaining" as you'd normally do with Futures is done using async/await, and not chaining one task to another.

Yes in asychronous context that is natural. However I am refering to the situation where you know that there is a spawned task you have to wait for but you are producing updates in synchronous context and can't wait for the result while having a need for producing a new update.

I would suggest we take this idea to the forums: https://forums.swift.org/

I will prepare something then. Thanks for response!