Missing CS8602 for calculated property

[eugene-rw]

Missing CS8602 for calculated property

[eugene-rw]

It seems, compiler incorrectly use condition "provider.NumberList != null" as proof of non-nullability of a

[huoyaoyuan]

It seems, compiler incorrectly use condition "provider.NumberList != null" as proof of non-nullability of a

It is the contract of property. Nullability analysis and many other analyzers doesn't expect the get result of property to change randomly. There are also other cases that tooling can invoke the getter of properties.

[eugene-rw]

@huoyaoyuan
I would agree, if it was simple variable. But nullability analysis can see that the property is function indeed, and doesn't relay on it constancy. It can be make as configurable though.

[huoyaoyuan]

But nullability analysis can see that the property is function indeed

Nullability analysis and potentially all language features doesn't see through method body of other methods. It only check for the signatures with attributes applied.

It's also impractical to understand what can happen in a method in detail.

I would agree, if it was simple variable.

It's the contract of properties to act similar to simple variables. Many of the tooling including debugger follow this contract.

[eugene-rw]

It's also impractical to understand what can happen in a method in detail.

Yes, of course.

I supposed, that there is a simple method to distinguish cases when property has simple get accessor with hidden backing field and when property calls function. But PropertyInfo has no info for that, it seems, that it can be compiler internals only.

[CyrusNajmabadi]

Closing as by design. Only the signatures of members are examined to determine their impact on NRT analysis.