Added: C# Language Design Notes for Mar 29, 2017

[MadsTorgersen]

C# Language Design Notes for Mar 29, 2017

1. Nullable scenarios
2. Span<T> safety

Please discuss.

[DavidArno]

I still have a semantics issue with the term "nullable reference types". Reference types are already nullable. Whilst it's more of a mouthful, "non-nullable reference types" is a better description and causes (me, at least) less confusion.

[DavidArno]

Oh, and welcome back from your holiday Mads and thanks for embracing the request that you post a discussion issue to accompany the meeting notes. 👍

[Joe4evr]

How much does a client of a newly annotated old library have to change in order to accommodate?
Example: If we are going to say that you annotate your locals, that might be more consistent with the rest of the language, but might also cause more code to need to be changed.

I'm not entirely sure I understand this bit correctly. If I'm using a library, and they update with nullable annotations, I expect to change code around them annotating their properties/method returns. I don't expect to change any of my code based on them annotating their locals because I can't see those anyway.

I still have a semantics issue with the term "nullable reference types". Reference types are already nullable.

True, but the history of this feature tells where they're coming from.

[orthoxerox]

@DavidArno technically, we're not getting non-nullable reference types, we're getting explicitly nullable reference types and implicitly nullable reference types plus a warning when the latter can be nulled.

[DavidArno]

@orthoxerox,

Um, thanks for the "clarification" 😀

To be honest, I'm confused as to whether you have a typo in what you said there. As I understand it, what we'll be getting is reference types that will yield warnings if the compiler determines they're null, unless they're explicitly marked as allowed to be null. Is that right?

[orthoxerox]

That's right.

[MadsTorgersen]

@DavidArno on the term "nullable reference types": I agree it isn't entirely appropriate. Neither is "non-nullable", for the reasons @orthoxerox pointed out. We just don't have a better name (yet), and are ok using the term colloquially for the time being.

Suggestions welcome!

[jnm2]

@MadsTorgersen I think we should call it private protected reference types 😆

[gulshan]

I suggest "Default non-nullable references" as I found nothing in the proposal to do with types like "nullable value types", which introduced new types and syntactic sugar around them. int and int? are two different types, while for proposed reference types typeof/default etc applied to classFoo and classFoo? will return same thing. What's funny is default of a non-nullable reference (type) will be null.