-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Change default of DefaultResponseReferenceTypeNullHandling to NotNull #2215
Conversation
You can still change this default back to how it is now (v12) |
I see another problem in the future: Even with Nullable Reference Types (C# 8) you cannot describe nullability with the Maybe it would be best to also add an |
BTW, some good news concerning the mentioned UI issue |
@StasPerekrestov good to know... what’s your opinion on the default? |
I don't know the whole history here but agree with this sentiment. Provide a well-documented override of this default and all would be well from my perspective.
Your point is valid but leave nullable reference types out of it: Knowing the compiler will allow a Agree a |
The problem here is the inconsistency from a user perspective: As a user in an NRT world, I'd expect that |
I guess, you are looking for something like Optional<T>/Maybe to avoid
using attributes, however usage of these patterns isn't common in c#
world...
…On Mon, Jun 10, 2019, 12:07 PM Rico Suter ***@***.***> wrote:
Your point is valid but leave nullable reference types out of it: Knowing
the compiler will allow a null assignment is very different from knowing
the user will assign null in some cases.
The problem here is the inconsistency from a user perspective: As a user
in an NRT world, I'd expect that typeof(Pet) is automatically treated as
not nullable and typeof(Pet?) is nullable (but this probably does not
compile, right?), but from a tooling perspective we cannot assume not
nullable because typeof(Pet?) is not allowed. As a user I'd like to
express nullability in the same way as I do it everywhere else (e.g.
parameters) - not with an additional property on the attribute...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2215?email_source=notifications&email_token=AAGMTTKPGBYC32FLGPAYFQTPZYKVZA5CNFSM4HVSWCIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXJK7EI#issuecomment-500346769>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGMTTKXBBQ7XY4PWRBZ6TDPZYKVZANCNFSM4HVSWCIA>
.
|
Or |
On one hand we have the issue described in the task,
On the other hand there is an issue related to reference types handling,
so, basically, we have two related issues.
In c# world we don't have to many options to go with. We need either to
wrap instances, e.g. Maybe monad, but c# doesn't have appropriate sugar
syntax to deal with it, or use Attributes to express the disired behavior.
…On Mon, Jun 10, 2019, 12:25 PM Rico Suter ***@***.***> wrote:
I guess, you are looking for something like Optional/Maybe to avoid
using attributes, however usage of these patterns isn't common in c#
world...
Or Nullable<T> but that's only for value types - however as a user I just
expect that Pet vs Pet? just works everywhere and thus I'm a bit worried
that people will be quite confused.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2215?email_source=notifications&email_token=AAGMTTM3JN2KAP3YQ76GFPTPZYMXLA5CNFSM4HVSWCIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXJMETY#issuecomment-500351567>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGMTTLLPY37HHTSPTFPM6TPZYMXLANCNFSM4HVSWCIA>
.
|
My point is that ideally this should have been solved with the C# 8 NRT feature somehow - right now However this PR is not really about NRT or C# 8 but about changing the default of DefaultResponseReferenceTypeNullHandling to NotNull and adding the "nullable" attribute to the xml docs (this will solve the problems for now). My big question is: What is the best default for DefaultResponseReferenceTypeNullHandling? |
What concerns me, is that XML docs now change the behavior of XML schema generation. This is something, not many developers are aware of and also may be a source of confusion. From my point of view, I'd rather look for an appropriate .net attribute to change the required behavior than for an attribute of XML doc. |
Regarding the new defaults, I'm OK with that. However, the information that describes the behavior and the way of changing it should be more easy to find. |
Yes, somehow you are right, but the alternative is extremely verbose:
I think it's the still the nicest way to do as xml docs attribute as it is the only way to avoid having specifying a single response code three times... Ideally there's just a |
This PR:
DefaultResponseReferenceTypeNullHandling
fromNull
toNotNull
.Details:
ProducesResponseTypeAttribute
. This could be solved with a new "nullable" attribute in the XML docs (which always wins if specified):x-nullable
property and thus the impact is lower.Sample operation:
With
DefaultResponseReferenceTypeNullHandling = Null
(current default, OpenAPI 3)With
DefaultResponseReferenceTypeNullHandling = NotNull
(new default, OpenAPI 3)Open questions:
/cc @pranavkm @dougbu What's your take on this?