53 lines
1.8 KiB
Markdown
53 lines
1.8 KiB
Markdown
# 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.
|
|
|