Unsafe evolution speclet: add more modifier restrictions

[jjonescz]

No description provided.

[333fred]

Why remove this detail?

[jjonescz]

It doesn't seem to be adding anything new. get/set methods are already members to which the kept sentence applies. And now with safe/unsafe keywords, the caller-safety can differ between the accessor and the containing member, so this detail would have to be modified somehow, so I just thought it's easier to remove it.

[333fred]

I think we should keep it. We can remove the line about auto-props, but this still impacts things such as the MoveNext of compiler-async or iterators.

[jjonescz]

this still impacts things such as the MoveNext of compiler-async or iterators.

Currently it actually does not. These members are not user-callable, and we don't emit [RequiresUnsafe] on them. (It's a good point that we should clarify that fact either way though.)

[333fred]

Users could use reflection to call them. We should make sure that synthesized members generated from an unsafe method are also marked as unsafe.

[jjonescz]

Users could use reflection to call them.

Not sure how does the fact whether [RequiresUnsafe] is on such members make a difference - unless users calling those members via reflection manually check that attribute and then do... what? add unsafe block (which IDE immediately declares as unnecessary)?

Perhaps I can just add an open question for now?

(FWIW, I don't think it was previously clear from that block of speclet that it would apply to things like MoveNext.)

[333fred]

It was certainly my intention that it apply to them. That's what I meant by hidden members generated by that user-facing member.