Skip to content

Latest commit

 

History

History
69 lines (45 loc) · 3.84 KB

LDM-2023-01-11.md

File metadata and controls

69 lines (45 loc) · 3.84 KB
Raw

C# Language Design Meeting for January 11th, 2023

Agenda

Quote of the Day

  • "It feels like someone is going to write a blog post about this."

Discussion

using aliases for any types

#4284

Today, we took a look at expanded using aliases, and open questions in the area. The LDM is generally in favor of the topic, but there are a few questions to resolve around specific areas of the proposal.

Pointer types in aliases

First, we looked at pointer types in using aliases. We've heard from function pointer users, since before the first preview was publicly released, that they would love to be able to using alias long function pointer types. This raises an interesting question: where are unsafety errors reported for such types? We don't have a using unsafe today, so would we want to introduce that? Or would we want to check at the use-site, and not give any warning or error in the using itself? We enumerated a few options:

  1. Don't allow pointer types in using aliases, even with #4284 implemented.
  2. Allow pointer types in using aliases, but introduce using unsafe and require it be present.
  3. Always allow pointer types in using aliases, and check for unsafety at the use site.

An initial read was nearly unanimously in favor of 3, but further discussion revealed key concern: An unused using alias might never be checked for pointer types, even if the project doesn't have unsafe turned on. This felt dangerous and likely to become an odd C# quirk that we would end up regretting. There was also some preference that we ensure that any pointer type syntactic usage is explicitly tied to unsafe in some fashion. We also think that using unsafe will actually be easier to implement, as it will avoid some circularity issues that we'd otherwise need to be concerned about.

Given these concerns, we are planning to go with option 2, and potentially relax during preview or in a future version of C# based on user feedback.

Conclusion

Option 2, potentially relaxing in the future based on user feedback.

Reference nullability in aliases

Next, we turned our attention to reference type nullability in aliases. Nested nullability is already allowed: using MyList = List<string?>;, for example. However, should we allow using NullableString = string?;? There are some good reasons not to:

  1. Complicates implementation and conceptual load by forcing us to guard against ? on nullable aliases.
  2. Usage in pattern matching is broken. These aliases couldn't be used directly, and { } patterns would need to fall to the underlying type.
    1. This might further change in #nullable disabled contexts.
  3. Display in quick info might change with nullable flow states: when an expression has been analyzed to be not null, it could require falling back to the non-aliased underlying type, which we think is unexpected behavior. This behavior would also vary between #nullable contexts.
Conclusion

Top-level nullability cannot be specified in using aliases.

Value nullability in aliases

Today, using NullableInt = Nullable<System.Int32>; is legal. However, given our previous decision, do we want to also forbid using NullableInt = int?;, and require users to continue using Nullable<T> for such locations? After some discussion, we think this is different than the previous point: string? and string are the same runtime type, while int and int? are actually different runtime types; there is no difference in behavior around #nullable contexts like there is for reference types.

Conclusion

Allowed.