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.

Sign up for GitHub

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

Jump to bottom

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
Labels
FrozenDueToAge Proposal
Milestone
Proposal

Comments

@carnott-snap
Copy link

carnott-snap commented Mar 3, 2021 •
edited
Loading

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
Copy link
Member

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
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 rsc mentioned this issue Jul 28, 2021
Open
@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
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
@rsc rsc moved this to Declined in Proposals Aug 10, 2022
@rsc rsc added this to Proposals Aug 10, 2022
@golang golang locked and limited conversation to collaborators Aug 11, 2022
@rsc rsc removed this from Proposals Oct 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
4 participants
@rsc @ianlancetaylor @gopherbot @carnott-snap