-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Add native lock speclet #7849
Add native lock speclet #7849
Conversation
> { | ||
> class Lock | ||
> { | ||
> public Scope EnterLockScope(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I updated the proposal in the Lock API review to rename this method back to EnterScope
, as the Lock
in the name is redundant given the type name and it's not being suggested for use as a general pattern anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's not being suggested for use as a general pattern anymore
I think that's still considered as future work (when ref structs can implement interfaces). Wouldn't it be better to keep the name EnterLockScope
to make the transition to the generic pattern smoother?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was under the impression that it may or may not be expanded to a general lock pattern, and figured we might as well use an appropriate name for now. If a general pattern is exposed in the future it may also be more useful for it to be usable by other existing types, which may also involve new syntax or some such. At that time if it's necessary to add EnterLockScope
again we could, and perhaps explicitly implement it if it's an interface member to hide it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I assume this can still change in API review. Do you know when the API will be approved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I don't think it's been scheduled yet, will add you when I find out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec should reflect our best guess for what the API will be. If API review changes the name we will just update the spec.
Based on previous experiences though we should put the name @kouvel least wants in the spec. Cause inevitably whatever we pick in the initial spec always changes 😉
Because Scope is a ref struct, awaits are not allowed anyway.
Proposal: #7104
Rendered markdown