Merge pull request #1423 from dotnet/design-notes
Add raw notes for Mar 28, 2018
This commit is contained in:
commit
63bd044471
52
meetings/2018/LDM-2018-03-28.md
Normal file
52
meetings/2018/LDM-2018-03-28.md
Normal file
|
@ -0,0 +1,52 @@
|
|||
# C# Language Design Notes for Mar 28, 2018
|
||||
|
||||
***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
|
||||
|
||||
Ranges
|
||||
|
||||
# Shipping a prototype
|
||||
|
||||
We would like to ship a prototype of ranges, in order to get feedback and settle the remaining decisions.
|
||||
|
||||
We would need to offer the Range type, maybe as a NuGet.
|
||||
|
||||
But it would also be nice to offer range-enhanced other types, like `Span<T>` and maybe arrays.
|
||||
|
||||
Maybe the compiler can fake out special indexers in the prototype. Or we also add extension indexers.
|
||||
|
||||
Tying it to revs of .NET Core previews may be too sluggish, and fraught with dependencies.
|
||||
|
||||
Or we create a wrapper type for Spans with the extra behavior, and smooth over the edges as best we can (implicit conversions etc)
|
||||
|
||||
## Conclusion
|
||||
|
||||
Let's do:
|
||||
|
||||
1. A temporary "language feature" that's extension indexers based on method names
|
||||
2. Range support in the language
|
||||
3. A preview NuGet package with `Range`, associated types and "extension indexers" on known types
|
||||
|
||||
|
||||
# Which feature?
|
||||
|
||||
We have two options:
|
||||
|
||||
1. Do like Python: just live with "0 from end" not being expressible as a number; it's a special case
|
||||
2. Add Index and ^
|
||||
|
||||
The first one is the more restrictive, and also the cheaper one (from both work and number of abstractions). This will help us understand whether people need the extra.
|
||||
|
||||
But not supporting "from end" is too restrictive; we have very good reason to believe people need that.
|
||||
|
||||
|
||||
# Nested stackalloc
|
||||
|
||||
Issue #1412, trivial to implement in 8.0, where the stack-spilling machinery is there anyway for pattern matching.
|
||||
|
||||
|
||||
# Exhaustiveness in switch expressions
|
||||
|
||||
Should non-exhaustiveness be an error or a warning? If warning, what should happen at runtime?
|
||||
|
||||
For now, it's a warning, and if you get there we throw a new exception type for this.
|
||||
|
Loading…
Reference in a new issue