* Added details and examples for null guard guidance
* Update proposals/csharp-8.0/nullable-reference-types.md
Co-Authored-By: Bill Wagner <wiwagn@microsoft.com>
Co-authored-by: Bill Wagner <wiwagn@microsoft.com>
* Copy from LDM proposal
* Partial Methods
* Put document in right directory
* Cleanup
* Typo
* Apply suggestions from code review
Co-Authored-By: Joseph Musser <me@jnm2.com>
Co-authored-by: Joseph Musser <me@jnm2.com>
* Really rough draft
* modreq vs. attributes
Finished up the section detailing using attributes vs. modreq. Decided
to make it an open question for now vs. a consideration. I felt less
strongly about it after writing it. I still do feel quite passionate
though about this with validators.
* Summary and motivation added
Got the basic summary and motivation added. Feeling good about the
premise here.
* Detailed design section
This ended up persuading me that `init` should be on the `set` method,
not the property itself. There is just too much in common with the
`readonly` modifier here. Plus if we ever decide to include the concept
of `init` members as a general feature then `init` would be required to
be on the `set`.
* Encoding discussions written
* Almost there
* Initial draft completed
* Remove init type modifier
After discussion in LDM we've decide against this as a feature. Reasons
captured in the document.
* Updated all notes
* Respond to LDM decisions
This updates to the following two LDM decisions:
1. Disallow `init` on fields
1. Use `init` instead of `init set`
* Cleaned up emit scenarios
* Apply suggestions from code review
Co-Authored-By: Fred Silberberg <fred@silberberg.xyz>
* Addressed some feedback
* Finish up PR feedback
Finish up the PR feedback on the proposal
* Typo
* PR feedback
* Apply suggestions from code review
Lots of typos 😄
Co-Authored-By: Tiago César Oliveira <4922781+tiagocesar@users.noreply.github.com>
Co-Authored-By: Patrick Westerhoff <PatrickWesterhoff@gmail.com>
Co-Authored-By: Steve Ognibene <steve.ognibene@namely.com>
Co-Authored-By: Viacheslav Ivanov <viacheslav.ivanov@gmail.com>
* Apply suggestions from code review
Co-Authored-By: Julien Couvreur <jcouv@users.noreply.github.com>
Co-Authored-By: Fred Silberberg <fred@silberberg.xyz>
Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
Co-authored-by: Tiago César Oliveira <4922781+tiagocesar@users.noreply.github.com>
Co-authored-by: Patrick Westerhoff <PatrickWesterhoff@gmail.com>
Co-authored-by: Steve Ognibene <steve.ognibene@namely.com>
Co-authored-by: Viacheslav Ivanov <viacheslav.ivanov@gmail.com>
Co-authored-by: Julien Couvreur <jcouv@users.noreply.github.com>
* Only allow static methods for applicable members
This fixes a very similar problem to https://github.com/dotnet/csharplang/issues/3277, where this code is unable to be resolved:
```cs
interface I1{}
interface I2{}
public unsafe class C : I1, I2 {
void M(I1 i) {}
static void M(I2 i) {}
public void M1() {
delegate*<C, void> a = M; // Ambiguous because both M's are applicable
}
}
```
With this change, the instance method M is not applicable, so there is no ambiguity.
Fixesdotnet/docs#13841
I added a note (first recommendation) but did not make any additions for the second. That's covered in more of the tutorials and conceptual docs.
