Closed ktoso closed 3 years ago
Not sure if we should hide init() then as well yet...
Agreed. I think, as you mentioned, both improve the readability and are better options than .empty
.
Not sure if we should hide init() then as well yet...
In case we have both "wrappers" in place I don't see a reason to make the BaggageContext
init more than private
.
Similar to Go, it could explain to people what they should do when a task starts "from zero" in "the background" somewhere.
Go does:
.background
- "this is meant to start from a zero context, a background task" so there's no request ID at all on those etc; this is better than "empty" because empty could be "I'm lazy" or "i really want to make a new fresh one".TODO("for some reason")
- this helps tremendously to signal the intent that "I'm just being lazy today" but it signals that this is just a placeholder that should be replaced with passing a real proper context around. It is then trivial to build tooling which disallows e.g. releasing with missing context propagation if TODO was used;StaticString
parameter can be used to force a reason info why one is not passing it around yetboth return empty context but they are easier to write code analysis for -- e.g. "don't release with TODO() contexts". I think this would be quite useful since you can prototype easily with TODO() and then you can add it around for real everywhere.