Enforcing patterns at the compiler level

(in case you're wondering, right now I'm cherry-picking a few comments people have asked me to write on. I'll get to them in order soon...)

Jonathan Crossland asked

.. your thoughts on enforcing patterns at the compiler level.
As an example:
- excluding the public scope from field declarations, making them private by default and only private.
- declaring a field as public appears as a compiler warning (level x)
or an abstract example
- putting accessors (constructor like) on the object level, so that we can code against someone setting an instance to another as in
myobj = yourobj (yourobj fires a get, myobj fires a set)

We haven't talked about this at length in the design meetings I've been at, but there is a big gap in my attendence.

Given that we already have an extendible tool like FXCop available, I don't think it makes sense for each compiler to do work that would duplicate the FXCop features. I'm fairly sure that both of your first examples can be done in FXCop now.

The abstract one could either be done by post-compile IL analysis, or it could be done by a compiler. Doing so in the compiler would be difficult to do in an general way, and our compiler architecture doesn't really lend itself to that sort of things.

Philosophically, it would be nice to have some way to leverage the knowledge that the compiler has about the code, but we don't currently have any plans in that area.

Jonathan, can you comment on why you want to be able to detect reference assignments? I'd like to understand the scenario better.