Allow TaskGroup's ChildTaskResult Type To Be Inferred

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

@jim

Question: How would errors be caught if we create Tasks with different return types? How would this surface in the IDE? Would it possibly more confusing than having a “ground truth” at the top of the statement?

My snippet pasted above directly answers this question, the error you get is the following (on that specific line):

@ktoso

  await withTaskGroup { group in
      group.addTask {
          ""
      }
      group.addTask {
          12 // pretty good error: Cannot convert value of type 'Int' to closure result type 'String'
      }
  }

You could still spell it out as withTaskGroup(of: String.self).

---

I'm pretty supportive of this, just need to verify if there's some unpredicted problem with this in practice.

We should also keep in mind that once we get ~Escapable types I hope we'll be able to get rid of the "with" in the API entirely, since an un-escapable task group could -- potentially -- then just be initialized:

func test() async {
  var group = TaskGroup(of: Int.self) // : ~Escapable 
  group.addTask {}

in which case I think the of isn't as confusing as it might be with the with... style tbh...

So that's another thing to consider as we evolve these APIs to become more ergonomic.