[Amend] SE-0469 Task names to include instance property

Good morning folks,
this isn't a full pitch/proposal, I'll do that after we discuss here.

@anthonylatsis recently noticed that we're missing an instance property on Task to get the task name:

let task = Task(name: "Hello") {}
task.name // missing

while we do offer as a static property on Task and on UnsafeCurrentTask only. In other words, we're missing an official way to read the task name from outside of the task.

This seems like a silly omission because we even promised in the proposal access to names through Jobs which is also "external", AND we just prepared lldb to read and print task trees including names.

Long story short, I'd like to propose we add the:

extension Task {
  /// Return task's name, if it was set during its creation.
  public var name: String?
}

API that I believe was an accidental omission noone noticed during review.

I don't really expect much opposition here, but wanted to follow the usual pitch -> proposal or amendment flow of API discussions we always do. I would suggest we fast-track accept this as an "amendment" to SE-0469: Task naming rather than running a whole proposal review for it during this busy period of the year.

29 Likes

Would the name be read-only or mutable?

2 Likes

Naïvely, I'd say this is just an oversight in the original proposal and you ought to shoehorn it in and amend that proposal. Errata, away!

4 Likes

Would the property be made retroactively available for Swift 6.2?

In my opinion, this seems more like an oversight than something requiring a full proposal. I would guess many people may have assumed there was an accessor.

I would hope the property is read-only.

(As an aside, I've been spreading the word about task naming in my Instruments course when we look at the Swift Tasks instrument - students are very happy about the addition.)

Names are immutable and we’re not changing that, so yeah read only.

As far as I can see we’re missing runtime entry points so we’re not able to make this available on old runtimes…

5 Likes

Thanks everyone for chiming in, it seems there's enough support on the forums and from core team members to treat this as an amendment. I'll prepare that and we'll see how the process unfolds for it.

PS: Funnily enough the implementation is NOT just a single line change but some lifetime fixes etc... but nothing we can't handle :slight_smile:

8 Likes

The LSG has decided to summarily accept this amendment; please feel free to discuss it further in the amendment announcement thread.

John McCall
Language Steering Group