Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: context: add Scoped #44751

Closed
carnott-snap opened this issue Mar 3, 2021 · 6 comments
Closed

proposal: context: add Scoped #44751

carnott-snap opened this issue Mar 3, 2021 · 6 comments

Comments

@carnott-snap
Copy link

carnott-snap commented Mar 3, 2021

background

I an effort to defensively shunt off potential background goroutines, I find myself doing this frequently:

func outer(ctx context.Context) {
        ctx, cancel := context.WithCancel(ctx)
        defer cancel()
        x, err := inner(ctx)
        // ...
}

description

It strikes me that an alias of context.Context could be implemented such that this gets sugared implicitly:

package context

// Scoped is a Context that is cancelled when the current function returns.
type Scoped = Context
func outer (ctx context.Scoped) {
        x, err := inner(ctx)
        // ...        
}

alternatives

Several proposals have spoken to removing or internalising context.Context in go2 and making it a first class language primitive. This would likely be prefer to this approach, but none of them went anywhere.

drawbacks

This is pretty far down the magic rabbit hole, and maybe this is actually an anti-pattern, but context.Context is one of the sharpest interfaces I deal with regularly, and this seems to have benefits. If this is an anti pattern, what is the alternative?

As this would be implemented in the runtime, it should not change the language spec. There is no requirement to modify any code, but it would likely turn out to be as viral as context.Context was.

@gopherbot gopherbot added this to the Proposal milestone Mar 3, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Mar 3, 2021
@ianlancetaylor
Copy link
Contributor

It sounds like you are suggesting that the compiler should recognize context.Scoped explicitly and treat it differently. That is, this is a language change. Currently the compiler doesn't know anything about the context package. Is that a correct summary?

@carnott-snap
Copy link
Author

Yeah, that sounds fair. I was trying to indicate that like garbage collection or unsafe, this would not be a change to the language specification.

@rsc
Copy link
Contributor

rsc commented Jul 28, 2021

It would be extremely unlikely for us to make a language change for a package like context.
Unsafe is in the language spec, and garbage collection is implicitly in the spec by virtue of not specifying any explicit deallocation.
Context is not.

@rsc rsc moved this from Incoming to Active in Proposals (old) Jul 28, 2021
@rsc
Copy link
Contributor

rsc commented Jul 28, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Aug 4, 2021

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc rsc moved this from Active to Likely Decline in Proposals (old) Aug 4, 2021
@rsc rsc moved this from Likely Decline to Declined in Proposals (old) Aug 11, 2021
@rsc
Copy link
Contributor

rsc commented Aug 11, 2021

No change in consensus, so declined.
— rsc for the proposal review group

@rsc rsc closed this as completed Aug 11, 2021
@golang golang locked and limited conversation to collaborators Aug 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

No branches or pull requests

4 participants