3.8 KiB
C# Language Design Notes for Mar 14, 2018
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Indexing without pinning
Fixed size buffer is formally a pointer, but when we are indexing it we don't need to materialize it as a pointer. We could stop requiring that even when the container is movable, and let you index fixed buffers that are movable.
Conclusion
Don't require fixed statement for indexing. Still unsafe operation. This not only makes the code a bit simpler, but can avoid significant overhead for pinning.
MVP Summit feedback
Records
People are interested in getting rid of the boilerplate. Some just worry about member-wise repetition, others also about value semantics.
Combines well with some (almost any!) sort of discriminated union feature to provide the value of F# and other functional languages, that you can see your whole data model on half a page.
Conclusion
This is important. We need to understand existing scenarios, and avoid a big cliff if you want to go advanced. We need to be super pragmatic.
We want both records and discriminated unions, and we succeed when both are independently useful but fit well together.
This is not a scenario for source generators. They may be able to address it, but for generally useful (not domain-specific) syntax like this, it should be a proper language feature.
Anonymous implementations
Lots of scenarios around adaptation and delegation. Implementing IEquatable and IComparable, or IEqualityComparer and IComparer.
Has some interaction with records or primary constructors, in that the context for construction is ambient, and you might want e.g. constructor bodies directly in the body of the "class".
Conclusion
If we can make it nice enough we are not adverse to this, but it probably doesn't have the highest priority.
Async Disposal
Yeah do it.
Some discussion more generally about easier alternatives to using. The simplicity of C++ RAII is attractive, maybe there are ways we can simplify, e.g. like F#'s use on variable declarations. Also defer statements.
Source generators
Lots of interest in that. This is not a language thing, it is more a Roslyn/tooling feature. Let's try to raise it with them.
Nullable
On-the-side annotations
Mostly useful during a transition period. May be a lot of work of only temporary importance. On the other hand, the lack of it may hinder adoption.
We should keep an open mind as to what such a feature would look like. But all versions we can think of have very significant challenges.
Note that a library vendor can annotate their public surface area without dealing with their own warnings.
Three phases:
- Annotate public surface area with intent
- Turning on warnings internally
- Annotating locals
Level 1 is a bit dangerous: you may be wrong about your intent if you don't check against your own source code. But it may be the least bad way of moving forward for a given library.
Adoption
There are challenges to adopting on existing code base that aren't there for new code.
Nullable constructors
Annoying when you initialize differently. Solution must be some combination of easier opt-out and more analysis.
We need to think about this more. This is when you trust someone else to initialize it, and you want to force them to do it with a non-null value.
Lazy isn't a problem, because the underlying field owns up to its nullability.
Warnings
There are certainly places where the same "null" leads to multiple dereferencing warnings. We could complain about only the first one. There may be other places where there are cascaded warnings. (Also the W warnings). We can probably satisfy most of these.
We have to keep an eye on common uses and make sure people have a decent experience.
Coming up:
More nullable (type parameters, special members/annotations) Triage Range