I'm not very worried about this. We can always have the compiler "know" about specific property wrappers and have extra semantic checks for Swift.TaskLocal structs. The proper check is that we don't want values of Swift.TaskLocal to be declared as non-global properties or local variables. This can be enforced in the type checker with an adhoc check if needed. It isn't really associated with the property wrapper - that is just the sugar that provides the type declaration.
About the design, why do you need the redundancy with two declarations:
enum ExampleTrace {
@TaskLocal(default: TraceID.empty)
static var traceID
}
struct TraceID {
static var empty: TraceID? = nil
}
Is it possible to condense this down to something like this?
enum ExampleTrace {
@TaskLocal
static var traceID : Int
}
ExampleTrace.traceID.get() // -> Int?
This gets back to my question above about "why have a distinguished 'default' value" instead of using optionals? TLS is fundamentally a scoped key/value store like a dictionary. Dictionaries can have values of arbitrary type, but handle the missing case by returning a "optional none" instead of storing a default value. I don't understand why TLS would diverge from that widely used practice.
-Chris