There's actually been a fair amount of conversation on this topic
lately. Most recently it came up in this thread:
https://groups.google.com/forum/#!searchin/golang-nuts/context|sort:date/golang-nuts/Lqoj5bNQxzg/5LUEYGHAGQAJ
My biggest worry about making it implicit is that it becomes hard to
tell what APIs actually respect cancellation via context. The context
package was introduced at a point when the language was already fairly
mature, so much of the standard library and ecosystem doesn't accept
context parameters, thus providing no (standard) way of canceling those
operations (though some packages have their own ad-hoc mechanisms).
I think if you were going to make the context implicit, to keep things
sane you'd also have to somehow ensure cancellation is "always"
respected. I know of two languages that provide this sort of mechanism
-- Erlang and Haskell -- but they do this by means of asynchronous
exceptions, which besides having their own pitfalls in the abstract,
would completely break essentially all of the resource cleanup code
written in Go today, by introducing race conditions, not to mention
fundamentally change how error handling has to work.
People have pointed out real problems with the current situation, but I
haven't seen a good solution yet.
-Ian
Quoting David Suarez (2019-01-24 12:02:15)
> First off, I am really loving Go overall.� I probably did what many do
> and started out with less Context use and now it is becoming a standard
> for a few tiers which I see was in a blog somewhere from Google as
> well.� What I haven't been able to find is if there has ever been a
> conversation on making it implicit vs. explicitly passed in method
> calls.� In java you can do this to grab, set a context variable and
> then pull it a few steps down the request cycle without explicitly
> adding it to method signatures in between.� Is there a specific reason
> it is not implicit (e.g. readability or other) or just a conversation
> that hasn't happened yet?� Should it be a feature request to minimize
> its use to only those areas it is really needed?�
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [1]golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit [2]https://groups.google.com/d/optout.
>
> Verweise
>
> 1. mailto:golang-nuts+unsubscr...@googlegroups.com
> 2. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
