Return Task
100% against this. In the previous thread I already explained why I see the cancellation as a must.
The ugly truth about the APIs that are “optional” is that most of the users will never do the “optional” thing. This is the same situation as when you make something “required” (like closing the file descriptor): people will forget it. APIs should try to prevent bugs “by design” by doing the “right thing” by default. In this situation, cancelling the child Task is the correct (and I would argue the ONLY) choice.
Renaming
Judging by the feedback in this thread, the proposal authors may come to the conclusion that the community favors the with[Automatic]Cancellation naming. I just want to say that I'm perfectly fine with withDeadline.
I feel like there is an overlap between the people who want the rename and those who suggest Tash.detached (or similar “Task outlives the withDeadline call” solution). For me, from the very beginning, it was natural that withDeadline will have to cancel the child Task before returning, which may be the reason why I see withDeadline as a suitable name. Cancellation is implied, because this is how it should work in cooperative multitasking.
Btw. If you want the child Task to outlive the withDeadline call then you should not use the with[Resource] naming convention.
Timeouts without time
Btw. Any official stance on the timeouts that are not connected to any Clock? (Mainly about the DeadlineError containing the instant.)