SE-0311: Task-local values

[Chris_Lattner3 (Chris Lattner)]

@ktoso

Yeah, it's pretty trivial to add this and I was about to do so right away.

I did get some some unhappy reactions about doing such one off check for these. It would be nice to get the core team chime in on this check explicitly, because various people on the team seem to have different opinions if this is a good idea or a terrible idea.

I don't speak for the core team, only for myself, but I think it would be fine to have an adhoc check for this. We aspire to have as much as possible in the library, but "perfection" shouldn't get in the way of "good".

@ktoso

This is the follow change mentioned here, so yes it's possible but it will look like this on use sites:

// @TaskLocal static var empty: TraceID? = nil
ExampleTrace.$traceID.get() // -> Int?
ExampleTrace.$traceID.withValue(1234) {
} 

If we do this style of API, it's at least consistent that we always have to use the $ . I don't see any way around it, because how types must be used in a property wrapper and it's projectedValue / wrappedValue. As in, we can't have it work with traceID.functions as that must be the wrapped value, and the wrapped value must be the "Access".

I think it is really really important to figure out the global variable story here. This approach with property wrappers is directly gunning for the recommendation that I was making. However, if we go that far, we should just make it a language thing, and allow traceID = 1234 and print(traceID) with language support.

The other direction to go is to more directly embrace the fact that this is an indirect lookup and is inherently scoped-dictionary-like. You could enable something like Task.locals[&traceID] (safe because traceID could be guaranteed to have be a global per the check above) or potentially use keypaths.

Another related design question is: is the withValue scoping mechanism is actually important to achieving your goals? As far as I can tell, it provides a very simple approach to make the path compression stuff work nicely: if you have child tasks, they can be cranking along and the parent can go ahead and make more scoped things happen without disturbing them.

However, there are alternative implementation approaches that would make this work (e.g. use the refcount machinery like the COW implementation does). This would allow you to decouple the scoping from the value setting, allowing you to provide a properly unstructured get/set sort of interface (which would be very familiar and dictionary like) but then also provide an explicit "SaveAndRestore" style scoping operation for those that want to make a change that only effects the code below in a lexical region.

-Chris