Fix formatting in 2015 LDM notes (#745)
This commit is contained in:
Petr Onderka
Julien Couvreur
parent
c6084741e4
commit
057c1fde48
|
|
@ -21,8 +21,8 @@ This is the first design meeting for the version of C# coming after C# 6. We sha
|
|||
|
||||
See also [Language features currently under consideration by the language design group](https://github.com/dotnet/roslyn/issues?q=is%3Aopen+label%3A%22Area-Language+Design%22+label%3A%221+-+Planning%22+ "Language Features Under Consideration").
|
||||
|
||||
1. Design process
|
||||
=================
|
||||
1\. Design process
|
||||
==================
|
||||
|
||||
We have had great success sharing design notes publicly on CodePlex for the last year of C# 6 design. The ability of the community to see and respond to our thinking in real time has been much appreciated.
|
||||
|
||||
|
|
@ -103,8 +103,8 @@ Agenda
|
|||
It's usually up to Mads to decide what's ready to discuss. Generally, if a design team member wants something on the agenda, they get it. There's no guarantee that we end up following the plan in the meeting; the published notes will just show the agenda as a summary of what was *actually* discussed.
|
||||
|
||||
|
||||
2. Themes
|
||||
=========
|
||||
2\. Themes
|
||||
==========
|
||||
|
||||
If a feature is great, we'll want to add it whether it fits in a theme or not. However, it's useful to have a number of categories that we can rally around, and that can help select features that work well together.
|
||||
|
||||
|
|
@ -237,8 +237,8 @@ Themeless in Seattle
|
|||
|
||||
|
||||
|
||||
3. Features
|
||||
===========
|
||||
3\. Features
|
||||
============
|
||||
|
||||
The Matrix above represents a feature set that's strongly connected, and should probably be talked about together: we can add kinds of types (e.g. tuples, records), we can add syntax for representing those types or creating instances of them, and we can add ways to match them as part of a greater pattern matching scheme.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@ Quote of the day:
|
|||
Agenda
|
||||
------
|
||||
|
||||
|
||||
1. Immutable types
|
||||
2. Safe fixed-size buffers
|
||||
3. Pattern matching
|
||||
|
|
@ -18,8 +17,8 @@ Agenda
|
|||
|
||||
See also [Language features currently under consideration by the language design group](https://github.com/dotnet/roslyn/issues?q=is%3Aopen+label%3A%22Area-Language+Design%22+label%3A%221+-+Planning%22+ "Language Features Under Consideration").
|
||||
|
||||
1. Immutable types
|
||||
==================
|
||||
1\. Immutable types
|
||||
===================
|
||||
|
||||
In research prototypes we've experimented with an `immutable` modifier on types, indicating that objects of the type are *deeply* immutable - they recursively do not point to mutable fields. Issue #159 describes the proposal in more detail.
|
||||
|
||||
|
|
@ -77,8 +76,8 @@ Some of the "cheating" in Roslyn (caching, free lists, etc) is for performance,
|
|||
In summary, we are unsure of the value. Let's talk more.
|
||||
|
||||
|
||||
2. Safe Fixed-Size buffers
|
||||
==========================
|
||||
2\. Safe Fixed-Size buffers
|
||||
===========================
|
||||
|
||||
Why are fixed-size buffers unsafe? We could generate safe code for them - at least when not in unsafe regions. Proposal described at #126.
|
||||
|
||||
|
|
@ -91,8 +90,8 @@ It would allow arbitrary types, not just primitive like today. That may be the b
|
|||
Not a high-pri, not one of the first we should commit to.
|
||||
|
||||
|
||||
3. Pattern matching
|
||||
===================
|
||||
3\. Pattern matching
|
||||
====================
|
||||
|
||||
A view on pattern matching:
|
||||
|
||||
|
|
@ -266,8 +265,8 @@ public class Point
|
|||
|
||||
The operator `is` is a particular way of specifying custom matching logic, similar to F# active patterns. We could imagine less ambitious ways, in particular if we just want to specify deconstruction and not additional logic. That's something to dive into later.
|
||||
|
||||
4. Records
|
||||
==========
|
||||
4\. Records
|
||||
===========
|
||||
|
||||
A value-semantics class like the above would be automatically generated by a "record" feature, e.g. from something like:
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ Agenda
|
|||
3. Classes with value semantics
|
||||
|
||||
|
||||
1. Internal implementation only
|
||||
===============================
|
||||
1\. Internal implementation only
|
||||
================================
|
||||
|
||||
We have a versioning problem in the Roslyn APIs that we suspect is somewhat common - that of inherited hierarchies.
|
||||
|
||||
|
|
@ -101,9 +101,8 @@ Conclusion
|
|||
We need to talk to the BCL team to decide whether we would consider either of these approaches sufficient to protect the evolvability of interfaces.
|
||||
|
||||
|
||||
|
||||
2. Tuples, records, deconstruction
|
||||
==================================
|
||||
2\. Tuples, records, deconstruction
|
||||
===================================
|
||||
|
||||
We are eager to look at language support for tuples. They should facilitate multiple return values from methods, including async ones, and a consumption experience that includes deconstruction.
|
||||
|
||||
|
|
@ -118,8 +117,8 @@ Are tuples just a specific kind of record? Are records just tuples with a name?
|
|||
The next point is one such exploration.
|
||||
|
||||
|
||||
3. Classes with values
|
||||
======================
|
||||
3\. Classes with values
|
||||
=======================
|
||||
|
||||
We explored a possible pattern for immutable classes. It may or may not be the right thing to do, but it generated a lot of ideas for features that would be possible with it, and that it would be interesting to pursue regardless of the pattern.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,9 +10,8 @@ Agenda
|
|||
2. Tuples <*we like the proposal, but there are several things to iron out*>
|
||||
|
||||
|
||||
|
||||
1. Destructible types
|
||||
=====================
|
||||
1\. Destructible types
|
||||
======================
|
||||
|
||||
Issue #161 is a detailed proposal to add destructible types to C#.
|
||||
|
||||
|
|
@ -96,9 +95,8 @@ People do struggle with `IDisposable` today. They don't know when things are `ID
|
|||
We would like to solve the problem in C#, and pick over this proposal for ideas, but we'd need to noodle with it to make it a better fit. It would need to integrate better with current `IDisposable`.
|
||||
|
||||
|
||||
|
||||
2. Tuples
|
||||
=========
|
||||
2\. Tuples
|
||||
==========
|
||||
|
||||
Issue #347 is a proposal for adding tuples to C#. The main guiding principle for the proposal is to enable multiple return values, and wherever possible design them in analogy with parameter lists.
|
||||
|
||||
|
|
@ -302,4 +300,4 @@ bool b = TryGet(out value);
|
|||
Conclusion
|
||||
----------
|
||||
|
||||
We'd very much like to support tuples! There are a number of open questions, as well as interactions with other potential features. We'll want to keep debating and experimenting for a while before we lock down a design, to make sure we have the best overall story.
|
||||
We'd very much like to support tuples! There are a number of open questions, as well as interactions with other potential features. We'll want to keep debating and experimenting for a while before we lock down a design, to make sure we have the best overall story.
|
||||
|
|
|
|||
|
|
@ -12,9 +12,8 @@ Agenda
|
|||
4. "If I had a [billion dollars](http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare)...": nullability <*daunting but worth pursuing*>
|
||||
|
||||
|
||||
|
||||
1. InternalImplementationOnly
|
||||
=============================
|
||||
1\. InternalImplementationOnly
|
||||
==============================
|
||||
|
||||
This was a last-minute proposal for C# 6 and VB 14 to recognize and enforce an attribute to the effect of disallowing non-internal implementation of an interface. It would be useful to represent "abstract hierarchies", while reserving the right to add new members at a later stage.
|
||||
|
||||
|
|
@ -25,9 +24,8 @@ Conclusion
|
|||
Let's not do this. We cannot enforce it well enough since old compilers don't know about it.
|
||||
|
||||
|
||||
|
||||
2. Should `var x = nameof(x)` work?
|
||||
===================================
|
||||
2\. Should `var x = nameof(x)` work?
|
||||
====================================
|
||||
|
||||
This was raised as issue #766.
|
||||
|
||||
|
|
@ -42,9 +40,8 @@ Conclusion
|
|||
This works the same as with any other construct, i.e.: not. This is not a special case for `nameof`, and it doesn't seem worth special casing to allow it.
|
||||
|
||||
|
||||
|
||||
3. Records
|
||||
==========
|
||||
3\. Records
|
||||
===========
|
||||
|
||||
There's general excitement around proposals such as #206 to add easier syntax for declaring "records", i.e. simple data shapes.
|
||||
|
||||
|
|
@ -83,9 +80,8 @@ Conclusion
|
|||
We'll keep thinking about this situation. A next step in particular is to reach out to teams that own the serialization and presentation technologies that we'd like to work well with.
|
||||
|
||||
|
||||
|
||||
Nullability and reference types
|
||||
===============================
|
||||
4\. Nullability and reference types
|
||||
===================================
|
||||
|
||||
The horrifying thing about null being allowed as a member of reference types is that it does not obey the contract of those types. Reference types can be null *and* reference types can be dereferenced, But dereferencing null is a runtime error! No wonder Sir Tony famously calls null pointers his "[billion dollar mistake](http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare)".
|
||||
|
||||
|
|
@ -137,4 +133,4 @@ Type inference and overload resolution generally make strengthening of return ty
|
|||
Conclusion
|
||||
----------
|
||||
|
||||
Moving C# to a place of strong guarantees around nullability seems out of the question. But that is not to say that we cannot come up with an approach that meaningfully reduces the number of null reference exceptions. We want to keep digging here to see what can be done. The perfect is definitely the enemy of the good with this one.
|
||||
Moving C# to a place of strong guarantees around nullability seems out of the question. But that is not to say that we cannot come up with an approach that meaningfully reduces the number of null reference exceptions. We want to keep digging here to see what can be done. The perfect is definitely the enemy of the good with this one.
|
||||
|
|
|
|||
|
|
@ -14,17 +14,17 @@ These two meetings looked exclusively at nullable/non-nullable reference types.
|
|||
4. Potentially useful rules
|
||||
5. Safely dereferencing nullable reference types
|
||||
6. Generating null checks
|
||||
1. Nullable and non-nullable reference types
|
||||
============================================
|
||||
|
||||
1\. Nullable and non-nullable reference types
|
||||
=============================================
|
||||
|
||||
The core features on the table are nullable and non-nullable reference types, as in `string?` and `string!` respectively. We might do one or both (or neither of course).
|
||||
|
||||
The value of these annotations would be to allow a developer to express intent, and to get errors or warnings when working against that intent.
|
||||
|
||||
|
||||
|
||||
2. Opt-in diagnostics
|
||||
=====================
|
||||
2\. Opt-in diagnostics
|
||||
======================
|
||||
|
||||
However, depending on various design and implementation choices, some of these diagnostics would be a breaking change to add. In order to get the full value of the new feature but retain backward compatibility, we therefore probably need to allow the enforcement of some or most of these diagnostics to be *opt-in*. That is certainly an uncomfortable concept, and adding switches to the language changing its meaning is not something we have much of an appetite for.
|
||||
|
||||
|
|
@ -36,8 +36,8 @@ There's an important upside though, in that it would allow you to gradually stre
|
|||
|
||||
|
||||
|
||||
3. Representation
|
||||
=================
|
||||
3\. Representation
|
||||
==================
|
||||
|
||||
The representation of the annotations in metadata is a key decision point, because it affects the number of diagnostics that can be added to the language itself without it being a breaking change. There are essentially four options:
|
||||
|
||||
|
|
@ -103,9 +103,8 @@ Probably the most damning objection to the wrapper structs is probably the degre
|
|||
We are currently leaning strongly in the direction of an attribute-based representation, which means that there needs to be an opt-in mechanism for enforcement of the useful rules to kick in.
|
||||
|
||||
|
||||
|
||||
4. Potentially useful rules to enforce
|
||||
======================================
|
||||
4\. Potentially useful rules to enforce
|
||||
=======================================
|
||||
|
||||
**Don't dereference `C?`**: you must check for null or assert that the value is not null.
|
||||
|
||||
|
|
@ -124,9 +123,8 @@ We are currently leaning strongly in the direction of an attribute-based represe
|
|||
We very much understand that these rules can't be perfect. The trade-off needs to be between adding value and allowing continuity with existing code.
|
||||
|
||||
|
||||
|
||||
5. Safely dereferencing nullable reference types
|
||||
================================================
|
||||
5\. Safely dereferencing nullable reference types
|
||||
=================================================
|
||||
|
||||
For nullable reference types, the main useful error would come from dereferencing the value without checking for null. That would often be in the shape of the null-conditional operator:
|
||||
|
||||
|
|
@ -154,9 +152,8 @@ More annoying is having to state the type again in `ns is string! s`. We should
|
|||
Whatever syntax we come up with here would be equally useful to nullable *value* types.
|
||||
|
||||
|
||||
|
||||
6. Generating null checks for parameters
|
||||
========================================
|
||||
6\. Generating null checks for parameters
|
||||
=========================================
|
||||
|
||||
There'd be no guarantees that a `string!` parameter actually isn't going to be null. Most public API's would probably still want to check arguments for null at runtime. Should we help with that by automatically generating null checks for `C!` parameters?
|
||||
|
||||
|
|
|
|||
|
|
@ -29,27 +29,24 @@ In this meeting we looked over the top [C# language feature requests on UserVoic
|
|||
A number of these are already on the table.
|
||||
|
||||
|
||||
|
||||
1. Non-nullable reference types
|
||||
===============================
|
||||
1\. Non-nullable reference types
|
||||
================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2320188-add-non-nullable-reference-types-in-c](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2320188-add-non-nullable-reference-types-in-c)
|
||||
|
||||
We're already working on this; see e.g. #1648.
|
||||
|
||||
|
||||
|
||||
2. Non-nullary constructor constraints
|
||||
======================================
|
||||
2\. Non-nullary constructor constraints
|
||||
=======================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2122427-expand-generic-constraints-for-constructors](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2122427-expand-generic-constraints-for-constructors)
|
||||
|
||||
It is odd that we only support the `new()` constraint for empty parameter lists. In order to generalize this, however, we'd need CLR support to express it - see #420.
|
||||
|
||||
|
||||
|
||||
3. Support for INotifyPropertyChanged
|
||||
=====================================
|
||||
3\. Support for INotifyPropertyChanged
|
||||
======================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2255378-inotifypropertychanged](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2255378-inotifypropertychanged)
|
||||
|
||||
|
|
@ -60,9 +57,8 @@ We think that this may be better addressed with metaprogramming. While we don't
|
|||
We'll keep watching the space and the specific scenario.
|
||||
|
||||
|
||||
|
||||
4. GPU and DirectX support
|
||||
==========================
|
||||
4\. GPU and DirectX support
|
||||
===========================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2730068-greatly-increase-support-for-gpu-programming-in-c](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2730068-greatly-increase-support-for-gpu-programming-in-c)
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3646222-enable-hlsl-directx-and-graphics-development-tool](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3646222-enable-hlsl-directx-and-graphics-development-tool)
|
||||
|
|
@ -74,9 +70,8 @@ One feature that could potentially improve such libraries would be the ability t
|
|||
Unfortunately, like other new constraints, such a numeric constraint facility would require new support from the CLR.
|
||||
|
||||
|
||||
|
||||
5. Generalized extension members
|
||||
================================
|
||||
5\. Generalized extension members
|
||||
=================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2242236-allow-extension-properties](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2242236-allow-extension-properties)
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2060313-c-support-static-extension-methods-like-f](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2060313-c-support-static-extension-methods-like-f)
|
||||
|
|
@ -88,18 +83,16 @@ This is a reasonable request. The main problem we have is that the current schem
|
|||
This is certainly one that we will look at further for C# 7.
|
||||
|
||||
|
||||
|
||||
6. More code analysis
|
||||
=====================
|
||||
6\. More code analysis
|
||||
======================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4428274-improve-code-analysis](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4428274-improve-code-analysis)
|
||||
|
||||
This feels like it is best addressed via Roslyn-based analyzers.
|
||||
|
||||
|
||||
|
||||
7. Extension methods in non-static classes
|
||||
==========================================
|
||||
7\. Extension methods in non-static classes
|
||||
===========================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3359397-allow-extension-methods-to-be-defined-in-instance](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3359397-allow-extension-methods-to-be-defined-in-instance)
|
||||
|
||||
|
|
@ -108,54 +101,48 @@ We were very cautious when we first introduced extension methods, and surrounded
|
|||
This seems fair enough, and we could loosen this restriction, though it's probably a relatively low priority work item.
|
||||
|
||||
|
||||
|
||||
8. XML comments
|
||||
===============
|
||||
8\. XML comments
|
||||
================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2709987-xml-comments-schema-customization-in-c](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2709987-xml-comments-schema-customization-in-c)
|
||||
|
||||
This is not a language suggestion.
|
||||
|
||||
|
||||
|
||||
9. Unmanaged constraint
|
||||
=======================
|
||||
9\. Unmanaged constraint
|
||||
========================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4716089-unmanaged-generic-type-constraint-generic-pointe](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4716089-unmanaged-generic-type-constraint-generic-pointe)
|
||||
|
||||
This would be great in order to enable pointers over type parameters. However, it requires CLR support.
|
||||
|
||||
|
||||
|
||||
10. Compilable strings
|
||||
======================
|
||||
10\. Compilable strings
|
||||
=======================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5592955-compliable-strings](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5592955-compliable-strings)
|
||||
|
||||
This is mostly addressed by `nameof` in C# 6; it's unlikely there is basis for more language level functionality here.
|
||||
|
||||
|
||||
|
||||
11. Mulitple returns
|
||||
====================
|
||||
11\. Mulitple returns
|
||||
=====================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2083753-return-multiple-values-from-functions-effortlessly](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2083753-return-multiple-values-from-functions-effortlessly)
|
||||
|
||||
We're already looking at addressing this through tuples.
|
||||
|
||||
|
||||
|
||||
12. ISupportInitialize
|
||||
======================
|
||||
12\. ISupportInitialize
|
||||
=======================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2094881-add-support-for-isupportinitialize-on-object-initi](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2094881-add-support-for-isupportinitialize-on-object-initi)
|
||||
|
||||
This suggestion addresses the need to perform validation upon initialization. While depending on the ISupportInitialize interface is probably too specific, it is interesting to ponder if there is a way to e.g. hook in after an object initializer has run.
|
||||
|
||||
|
||||
|
||||
13. ToNullable
|
||||
==============
|
||||
13\. ToNullable
|
||||
===============
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2531917-structure-all-nullable-values](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2531917-structure-all-nullable-values)
|
||||
|
||||
|
|
@ -164,9 +151,8 @@ This suggestion would add a new operator to make type parameters nullable only i
|
|||
You could certainly imagine something like this in conjunction with at least some variations of the nullability proposals we have been discussing lately.
|
||||
|
||||
|
||||
|
||||
14. Statement lambdas in expression trees
|
||||
=========================================
|
||||
14\. Statement lambdas in expression trees
|
||||
==========================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4255391-let-lambdas-with-a-statement-body-be-converted-to](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4255391-let-lambdas-with-a-statement-body-be-converted-to)
|
||||
|
||||
|
|
@ -177,9 +163,8 @@ This would be a lovely gap to fill, especially since it would come with no conce
|
|||
It is also possible that we'd address a subset.
|
||||
|
||||
|
||||
|
||||
15. Language support for Lists, Dictionaries and Tuples
|
||||
=======================================================
|
||||
15\. Language support for Lists, Dictionaries and Tuples
|
||||
========================================================
|
||||
|
||||
[http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2405699-build-list-dictionary-and-tuple-into-the-language](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2405699-build-list-dictionary-and-tuple-into-the-language)
|
||||
|
||||
|
|
|
|||
|
|
@ -33,9 +33,8 @@ As follows:
|
|||
Some of these were discussed again (see below), some we just reiterated our position.
|
||||
|
||||
|
||||
|
||||
1. Ref returns and locals
|
||||
=========================
|
||||
1\. Ref returns and locals
|
||||
==========================
|
||||
|
||||
At the implementation level these would require a verifier relaxation, which would cause problems when down targeting in sandboxing scenarios. This may be fine.
|
||||
|
||||
|
|
@ -58,9 +57,8 @@ This feature would be a decent performance win for structs, but there aren't a l
|
|||
Even so, we are still a bit concerned that the scenario is somewhat narrow for the complexity the feature adds. The proof will have to be in the use cases, and we're not entirely convinced about those. It would be wonderful to hear more from the community. This is also a great candidate for a prototype implementation, to allow folks to experiment with usability and performance.
|
||||
|
||||
|
||||
|
||||
2. Readonly locals and parameters
|
||||
=================================
|
||||
2\. Readonly locals and parameters
|
||||
==================================
|
||||
|
||||
At the core this is a nice and useful feature. The only beef we have with it is that you sort of want to use `readonly` to keep your code safe, and you sort of don't because you're cluttering your code. The `readonly` keyword simply feels a bit too long, and it would be nice to have abbreviations at least in some places.
|
||||
|
||||
|
|
@ -71,9 +69,8 @@ In Swift they use `let` but it reads strange in some contexts. In Swift it's opt
|
|||
This is promising and we want to keep looking at it.
|
||||
|
||||
|
||||
|
||||
4. Does Not Return
|
||||
==================
|
||||
4\. Does Not Return
|
||||
===================
|
||||
|
||||
It would be useful to be able to indicate that a method will never return successfully. It can throw or loop.
|
||||
|
||||
|
|
@ -90,9 +87,8 @@ If through nasty tricks you get to a point in the code that according to never t
|
|||
A common usage would be helper methods to throw exceptions. But throw as an expression is the most useful thing out of this.
|
||||
|
||||
|
||||
|
||||
6. Attributes on lambdas
|
||||
========================
|
||||
6\. Attributes on lambdas
|
||||
=========================
|
||||
|
||||
Why? Guiding an analyzer, e.g. to prevent variable capture. Syntactically it might collide with XML literals in VB.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,15 +15,15 @@ Agenda
|
|||
4. Tuples
|
||||
5. Records
|
||||
6. Pattern matching
|
||||
1. Overall direction
|
||||
====================
|
||||
|
||||
1\. Overall direction
|
||||
=====================
|
||||
|
||||
In these first two months of design on C# 7 we've adopted a mix of deep dive and breadth scouring. There's agreement that we should be ambitious and try to solve hard problems, being willing to throw the result away if it's not up to snuff. We should keep an open mind for a while still, and not lock down too soon on a specific feature set or specific designs.
|
||||
|
||||
|
||||
|
||||
2. Nullability features
|
||||
=======================
|
||||
2\. Nullability features
|
||||
========================
|
||||
|
||||
Non-nullable types are the number one request on UserVoice. We take it that the *underlying problem* is trying to avoid null reference exceptions. Non-nullable types are at best only part of the solution to this. We'd also need to help prevent access when something is *nullable*.
|
||||
|
||||
|
|
@ -53,9 +53,8 @@ TypeScript uses information about type guards to track union types in if branche
|
|||
A core nuisance with nullability checking is that it raises a wealth of compat questions that limit the design in different ways. There may need to be some sort of opt-in to at least some of the diagnostics you'd get, since you wouldn't want them if you were just recompiling old code that used to "work".
|
||||
|
||||
|
||||
|
||||
3. Performance and reliability
|
||||
==============================
|
||||
3\. Performance and reliability
|
||||
===============================
|
||||
|
||||
The list produced at a recent design meeting (#1898) looks sensible.
|
||||
|
||||
|
|
@ -112,9 +111,8 @@ Destructible types
|
|||
The scenario is good, not the current proposal.
|
||||
|
||||
|
||||
|
||||
4. Tuple types
|
||||
==============
|
||||
4\. Tuple types
|
||||
===============
|
||||
|
||||
There's agreement on wanting the feature and on the syntax (#347, #1207).
|
||||
|
||||
|
|
@ -123,9 +121,8 @@ We probably prefer a value type version of Tuple<T>. Of course those would be su
|
|||
There are performance trade offs around allocation vs copying, and also around generic instantiation. We could do some experiments in F# source code, which already has tuples.
|
||||
|
||||
|
||||
|
||||
5. Records
|
||||
==========
|
||||
5\. Records
|
||||
===========
|
||||
|
||||
See #180, #206, #396, #1303, #1572.
|
||||
|
||||
|
|
@ -144,9 +141,8 @@ Serialization has to work *somehow*, even though many of the members will be gen
|
|||
We should not be *too* concerned about the ability to grow up to represent all kinds of things. Start from it being the POD feature, and work from there.
|
||||
|
||||
|
||||
|
||||
6. Pattern matching
|
||||
===================
|
||||
6\. Pattern matching
|
||||
====================
|
||||
|
||||
See #180, #206, #1572.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue