New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support readonly fields #6202

Closed
ajcvickers opened this Issue Jul 28, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@ajcvickers
Member

ajcvickers commented Jul 28, 2016

Note that this issue is talking about readonly fields, not properties. That is, fields that are decalred as readonly or generated from read only auto properties. They have the "initonly" flag set in CLR metadata.

The issues:

  • The expression compiler won't compile an Assign expression to a field with "initonly" flag set. Exception is: " Expression must be writeable". So normal mechanism for compiling a delegate to set the field doesn't work.
  • If you get around that, for example by creating the expression tree with the AssignBinaryExpression directly (using Reflection since this is internal), you then get an exception from the expression compiler: "VerificationException: Operation could destabilize the runtime."

The only way to set the field that works is using Reflection with FieldInfo.SetValue. We can compile this method call into the expression tree (only doing so if "initonly" flag is set). Since the FieldInfo is cached performance is not horrendous, but it is a lot worse than just compiling an assign--approximately 100 times slower.

So the question is should we use Reflection for this, or should we throw saying not to use readonly fields or read only auto-properties?

Keep in mind that we will support these types of fields in some scenarios when we support materialization through parameterized constructors. This would be ideal for normal materialization, but it won't support things like key propagation or fixup.

@rowanmiller

This comment has been minimized.

Show comment
Hide comment
@rowanmiller

rowanmiller Jul 29, 2016

Member

We'll throw for the moment and can always support it later.

Member

rowanmiller commented Jul 29, 2016

We'll throw for the moment and can always support it later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment