-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Stop throwing eagerly when looking up a ValueGenerator #32930
Conversation
The #32892 has been marked as a Servicing Consider 8.0.x label. The description above indicates this is a breaking change. |
@SamMonoRT We may want to do a somewhat less clean version of the fix that isn't a break when take this to the servicing branch. I would like to hear what the @dotnet/efteam thinks. |
I think we should still throw this for non-composite keys, as it would be a more useful exception than a "key not set" |
eee787c
to
a05f31d
Compare
@AndriySvyryd @SamMonoRT New version up that retains the behavior of throwing for non-composite keys. Also changed the break into an obsolete. We can't port this directly to release/8.0, but if this is the correct fix going forward, then I'll look at the port next. |
Fixes #32892 The issue was introduced by the fix for stable/unstable values. In that fix, we were missing that a value generator exists and influences whether the generated value is considered stable or not. However, some types, most notably bools, don't have a default generator. This is fine, it just means that there isn't a generator to use. I removed the exception entirely because we never now throw if we can't find a generator--it's always okay. This is technically a breaking change, and people do create their own selectors, so we should probably doc it.
…e keys set for generation without any generator.
a05f31d
to
5cb7511
Compare
* Stop throwing eagerly when looking up a ValueGenerator Fixes dotnet#32892 The issue was introduced by the fix for stable/unstable values. In that fix, we were missing that a value generator exists and influences whether the generated value is considered stable or not. However, some types, most notably bools, don't have a default generator. This is fine, it just means that there isn't a generator to use. I removed the exception entirely because we never now throw if we can't find a generator--it's always okay. This is technically a breaking change, and people do create their own selectors, so we should probably doc it. * Update to remove the breaking change and still throw for non-composite keys set for generation without any generator. * Remove interface default implementation
Fixes #32892
The issue was introduced by the fix for stable/unstable values. In that fix, we were missing that a value generator exists and influences whether the generated value is considered stable or not. However, some types, most notably bools, don't have a default generator. This is fine, it just means that there isn't a generator to use.
I removed the exception entirely because we never now throw if we can't find a generator--it's always okay. This is technically a breaking change, and people do create their own selectors, so we should probably doc it.