103 lines
3.8 KiB
Markdown
103 lines
3.8 KiB
Markdown
# 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:
|
|
|
|
1. Annotate public surface area with intent
|
|
2. Turning on warnings internally
|
|
3. 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|