LDM Notes for May 9th, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-05-09.md

Agenda

1. Numeric IntPtr
2. Ref readonly parameters

[huoyaoyuan]

Interesting thought about IDE0049:

Most people prefer to use int instead of Int32 since it exists from the start. However, they may already have existing usages of IntPtr and do not want to convert it to nint.
I assume by "regard nint as simple alias for IntPtr", their relationship will be like int and Int32.

IDE0049 could be configurable on whether to use nint as an alias for IntPtr.

This is a IDE tooling stuff, not a language one, but I'd like to mention it here.

[CyrusNajmabadi]

Thanks for the info. Generally speaking though, we will update this to now match the semantics of the language. If these are identical, then that analyzer/fixer will suggest and fix these types along with the rest it currently handles.

[huoyaoyuan]

People may be conservative about their code. They will want an option that only apply the rule to the aliases exists from the beginning of the language.

[CyrusNajmabadi]

If a user is conservative, they can set this rule to just be a suggestion (or disable entirely). It is not an ide goal to provide total customization for all features for all needs.

[huoyaoyuan]

It's the first time I hear about Midori's history about refs. It does become important to reduce any overhead in system programming.

The current proposed ref safety rule is not straightly understandable for me. Maybe because it's for implementation of compiler, not for users. Could we take some experience from Rust? Can we implement a "cut" version of Rust's rule first, in order to support necessary usages for Span?

[333fred]

That is exactly what ref fields is doing.

[huoyaoyuan]

It's good to hear that. I want simpler explanation of the rules, and potentially a roadmap how we can improve the rule in the future without breaking.