# C# Language Design Notes for Nov 6, 2017

***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***

# Roslyn 20870

Protecting the client from unintended dependencies. But also protects from servicing. Today people going through reflection *know* they're being bad. Would this give enough sense that they are doing something special.

It would make consumers lazy about contacting the API owner about things they need exposed.

It would be an arms race - we would want the `IgnoreIgnore...` attribute to *really* protect things.

People will still have expectations about dependencies even if it was "their own fault" by using this attribute.

## Conclusion
Too risky/fishy in too many ways. 


# Roslyn 17310

There is no good language level solution right now. This is better addressed with an analyzer, which can know specifically about SpinLock (for instance).

In time, when readonly struct declarations are added, as well as maybe the ability to declare individual struct members as readonly, *then* maybe we could start warn.

## Conclusion

Not at the language level


# Roslyn 20450

We have sympathy. It feels like a corner that's cut. But it's quite expensive to implement, and has semantic dark corners (`List<>.First.Foo`).

## Conclusion

Not now.


# Roslyn 20015

When default-expressions are constant (according to the language) this is not interesting expressiveness - there's a literal you can use.

When they are *not* it gets a bit more interesting - you might want to check that your custom struct is zero-initialized. But you can do that with equality. Even in recursive scenarios, you can just `var`-pattern it and check in `when` or `&&`.

Additionally there is some concern about the target type being clear enough for the `default` expression.

## Conclusion

No.





