| 05:16 | <Steve Hicks> | Catching up on a lot here. I think I'm starting to come around a bit more to Stephen's perspective w.r.t. context flowing out from resolves. I think he's right that, in general (when people do the right thing) it ends up maintaining the same root for the context tree, since the resolved promise generally comes from earlier in the same scope, and I like the fact that it aligns the opt-in for registration time with something that's actually quite reasonable to implement. I believe it's also pretty trivial to do a paranoid await-wrapping: `await bindTask(() => untrustedApi())` which would guarantee the untrustedApi can't change the context on you. Where it still feels wrong to me is Andreu's concern. The really nice property in the current proposal is that it's really well encapsulated. Context variable behave just like lexical consts, where you have guarantees that anything you can't see can never change them out from under you, and that's a _very attractive_ guarantee. Whereas the flows-out approach seems very brittle if any single bad/careless actor anywhere in your downstream call chain is able to irretrievably break the flow. I think that's where this disconnect is coming from - the encapsulation purists in the group are very hesitant to give up that guarantee. I wonder if there's some middle ground where you could at least detect when an abrupt context change has occurred? For instance, I could imagine something along the lines of `using _ = contextMonitor();` at the top of the function. It could install a new variable and if it detected that the variable has changed at the end of the scope, it knows something fishy has happened. And if we're giving up the encapsulation, I suspect mutating variables with `using` might actually be reasonable as well... |
| 21:25 | <littledan> | If you are coming around to this point, do you have ideas about answers to the questions I was asking? Namely, what do we hope to get from merge points, which happen all the time? |
| 21:26 | <littledan> | Restoring around awaits isn’t purely losing information; it also maintains half of it which is also relevant |
| 21:37 | <littledan> | I’d kinda suspect that application code would have pretty low uptake of things like bindTarget and contextMonitor. It’s hard for me to understand how an application developer should decide which of the two options is appropriate. |