8 ms·

First C# 7 Design Meeting Notes

154 points by Romoku 12y ago

x0x0 12y ago
As a java programmer, who is involved in some large projects that can't be ported, I'm really jealous. And eagerly waiting to see how well the .net core runtime targets linux and mac. Good, no copy interop with native code would also be awesome. Particularly for machine learning.
- mike_hearn 12y ago
  The Java world moves on too, you know. A lot of the features that are listed as things that would be nice to have in C# already exist in Kotlin, which has been created by JetBrains to be fully drop-in compatible with Java. To the extent that it has a hotkey that automatically rewrites a Java class into Kotlin, and the entire project keeps compiling and working (they have full/close to perfect interop). For example, Kotlin has: • Nullability in the type system • Good support for efficient functional programming, e.g. you can do collection.map { it * 2 } and it's as fast as an imperative for loop as the compiler inlines the block. • Strong support for meta-programming / DSL features, so there's less need to make code generators. JetBrains are still working on this but basically the language has a lot of features that don't initially seem all that significant, but can be combined to create useful DSLs. • Lightweight data classes that support immutability and editing via copy construction (using named arguments) • Traits • Delegation • etc etc ... and it's all here today, with good IDE support, and compatible with Java 6 even. For good native interop there is JNA and there's a research project over at Oracle looking at how to do something better than JNA directly integrated with the JVM in a future version. So don't be too jealous.
  - pjmlp 12y ago
    There is a big difference between being the platform's system programming language and a third party language. Specially in the eyes of managers.
  - dodyg 12y ago
    I wish they kept the Pattern Matching support.
MichaelGG 12y ago
Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though. What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.
- deleted 12y ago
  [deleted]
- riffraff 12y ago
  doesn't C# already have structs ? how are records different from that?
  - sanxiyn 12y ago
    Structs have names. Records don't. See http://en.wikipedia.org/wiki/Nominal_type_system http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system.
  - nikbackm 12y ago
    http://stackoverflow.com/questions/5858550/f-records-vs-net-struct http://stackoverflow.com/questions/5858550/f-records-vs-net-...
  - jameshart 12y ago
    C# has anonymous types, which are closer to records, but there's no way to refer to a particular type structure. So while I can write var x = { FirstName = "Riff", LastName = "Raff" } and then go ahead and access x.FirstName and x.LastName, I can't declare a method signature like this: void Display({ string FirstName, string LastName } nameRecord) { } This is the kind of thing which is being proposed (along with possible pattern matching/decomposition syntax which is new ground for C#)
coldtea 12y ago
If only the open source languages we use had that many resources and paid developers... (Well, technically C# and the related libs are fully OSS now too, IIRC).
- pherocity_ 12y ago
  They are including almost all the frameworks you would use as well. They weren't set up to take pull requests, and I suspect that they're only interested in bug fixes. So, not entirely genuine.
- antics 12y ago
  C# isn't "technically" open source, it's just open source. If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here: https://github.com/dotnet/corefx/wiki/Contributing https://github.com/dotnet/corefx/wiki/Contributing
  - coldtea 12y ago
    IIRC, they (MS) said would steer the language and .NET libs, and not involve a community style effort (because they want to ensure compatibility for their customers), did they change that?
    - jacquesm 12y ago
      Of course they would, it's their project after all. So you can contribute but with that in mind, it's about as open as any corporation is going to be when it comes to accepting input from the world at large. At least they got that bit right.
    - MichaelGG 12y ago
      That's not different than some open source projects and has no bearing on it being open source. Some project leads call attempted contributors idiots and refuse to even fix security bugs. Some have differing visions for their project. Which projects run by a strict vote, and how would you even decide who gets to vote? Most likely you'd elect leaders that will vote in the benefit of the project... Which is what MS has effectively done.
Rapzid 12y ago
I would LOVE for C# to get language support for go style channels complete with select and friends. C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~ And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by about 40% :| It feels like in theory it should be compiled down to code with the same efficiency? This is probably more of a CLR/JIT issue though?
- radicalbyte 12y ago
  40% is nothing, the last time I tested jquery.each vs a for loop, the for loop was at least 50x faster.
- Cakez0r 12y ago
  You can already get a long way towards channels by using reactive extensions (E.G. http://pastebin.com/h1xteunX http://pastebin.com/h1xteunX) Some syntactic sugar a la await could be nice though.
  - theflagbug 12y ago
    Not sure if you're aware, but your Rx example has a few problems: 1.) In the StartSenders method, you're violating the Rx grammar by calling channel.OnNext concurrently. Wrap it on a lock statement. 2) In StartReceiver you're missing out messages the way you handle the channel. Replace the loop with a call to channel.Subscribe
    - Cakez0r 12y ago
      I did not know either of those things! Thanks!
- rjbwork 12y ago
  If you mean what I think you mean by "manually currying", it's likely because behind the scenes, there is a proxy class created for most (all?) lambdas that contains everything it needs to execute, including any scope variables maintained. So there's some extra overhead there, though not as much as you'd expect since everything, even value types, are pulled in by reference in the context of lambdas.
jpgvm 12y ago
If even 50% of this makes it into C# it's going to be a pretty amazing language. Native code interfaces were already reasonably fast, allowing more no copy semantics and array slice behaviour is going to do wonders for native library performance.
- Cakez0r 12y ago
  I really hope they implement this. It would make IO so much more efficient if you could pin a big chunk of memory and allocate buffers from it.
vans 12y ago
I think it's too late for non null ref types. But pattern matching, traits and built in code contract would be awesome !
- ColinDabritz 12y ago
  Non-nullable reference types have been called an impossible problem, but so was 'Await in catch and finally blocks' which shipped in C# 6. From http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-features-in-c-6.aspx http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-fea... "Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all." I'm hoping this is one of those 'Clark's first law' situations: http://en.wikipedia.org/wiki/Clarke's_three_laws http://en.wikipedia.org/wiki/Clarke's_three_laws 'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.' They've got quite a lot of smart folks working on C#, and it's heartening to me to see them taking another look at non-nullable reference types.
  - pbz 12y ago
    It would be such an important feature that I'd be willing to tolerate breaking changes -- the language designers may not however.
mhomde 12y ago
I've been trying to think of something that drastically change how I coded. Bugs and productivity really are the two major dragons to slay. I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre conditions etc would really make things cleaner. Current implementation feels like it requires too much setup with separate classes, duplicate method signatures in several places etc etc. It would be really cool to have something like public int SomeMethod(int a, int b) pre { Requires (a > 5); Requires (b >= 0, new Exception("something something")); } { // DoStuffHere } post { Ensures (result > 0, new Exception("needs to be above 0")); } I'd even want to be able to separate it into separate files using partial classes (or something) so you could the condition stuff separate , with or without duplicating signature depending if you wanted to target specific overloads Full signature would simply be without the body: public int SomeMethod(int a, int b) pre { Requires (a > 5); Requires (b >= 0 ,new Exception("something something")); } post { Ensures (result > 0); } Without signature is trickier, but would be cool since you could use same conditions for several overloads, and just target the variables that are included in each: Conditions.SomeMethod { pre { Requires (a > 5); Requires (b >= 0, new Exception("something something")); } post { Ensures (result > 0); } } heck, why not even throw in "test blocks" and Visual studio could run light-weight kind of unit test as you programmed and mark the whole method as functioning or not. Imagine having a sort method and throw in something like: public IEnumerable<int> Sort (IEnumerable<int> list, Order order) test { (list = {3,5,6,2}, order = Order.Ascending) => result == {2,3,5,6}; (list = {3,5,6,2}, order = Order.Descending) => result == {6,5,3,2} } VS could highlight the failed test(s) directly in the editor as you coded The specifics and syntaxes of these things requires some thought but I love the basic premise, am I rambling? edit: I saw that something in this direction if not as extensive was actually discussed
- pjmlp 12y ago
  You kind of used D's syntax for contracts, http://dlang.org/contracts.html http://dlang.org/contracts.html
bartwe 12y ago
I'd like some method to write GC-less code for games. Structs with copy constructors and destructors perhaps.
talles 12y ago
> Method contracts Oh god, I want it SO BAD.
DrDimension 12y ago
I cannot help but think that the overwhelming desire to support immutability and functional constructs here, as well as in nearly all other modern languages, gives significant evidence that functional programming is finally winning out over OOP. In the future, I hope that FP will be the default design choice, with objects being used where needed such as for components, plug-ins, and ad-hoc dictionary-passing-style tools. After all, simplicity is the most important property of any software system - http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
- noblethrasher 12y ago
  Immutability was never incompatible with OOP, just the opposite in fact. Even Alan Kay often criticized languages like C++ and Java for encouraging the use of setters and, thus, “turning objects back into data structures”. C# is still one of my favorite languages (even though I use F# most of the time now), but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; it's too bad that fact was lost on so many programmers. Kudos for sharing the Rich Hickey video; it's one of my favorites of all time.
  - azth 12y ago
    > but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.
    - noblethrasher 12y ago
      You have to go through the extra ceremony of writing a setter.
      - azth 12y ago
        The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void bar() { this.x += 1; // Whoops! } } Foo x = new Foo(); x.bar(); // Mutating call. Which Java does not prevent.

154 points by Romoku 12y ago

x0x0 12y ago

As a java programmer, who is involved in some large projects that can't be ported, I'm really jealous. And eagerly waiting to see how well the .net core runtime targets linux and mac. Good, no copy interop with native code would also be awesome. Particularly for machine learning.

mike_hearn 12y ago
The Java world moves on too, you know. A lot of the features that are listed as things that would be nice to have in C# already exist in Kotlin, which has been created by JetBrains to be fully drop-in compatible with Java. To the extent that it has a hotkey that automatically rewrites a Java class into Kotlin, and the entire project keeps compiling and working (they have full/close to perfect interop). For example, Kotlin has: • Nullability in the type system • Good support for efficient functional programming, e.g. you can do collection.map { it * 2 } and it's as fast as an imperative for loop as the compiler inlines the block. • Strong support for meta-programming / DSL features, so there's less need to make code generators. JetBrains are still working on this but basically the language has a lot of features that don't initially seem all that significant, but can be combined to create useful DSLs. • Lightweight data classes that support immutability and editing via copy construction (using named arguments) • Traits • Delegation • etc etc ... and it's all here today, with good IDE support, and compatible with Java 6 even. For good native interop there is JNA and there's a research project over at Oracle looking at how to do something better than JNA directly integrated with the JVM in a future version. So don't be too jealous.
- pjmlp 12y ago
  There is a big difference between being the platform's system programming language and a third party language. Specially in the eyes of managers.
- dodyg 12y ago
  I wish they kept the Pattern Matching support.

MichaelGG 12y ago

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though. What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.

deleted 12y ago
[deleted]
riffraff 12y ago
doesn't C# already have structs ? how are records different from that?
- sanxiyn 12y ago
  Structs have names. Records don't. See http://en.wikipedia.org/wiki/Nominal_type_system http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system.
- nikbackm 12y ago
  http://stackoverflow.com/questions/5858550/f-records-vs-net-struct http://stackoverflow.com/questions/5858550/f-records-vs-net-...
- jameshart 12y ago
  C# has anonymous types, which are closer to records, but there's no way to refer to a particular type structure. So while I can write var x = { FirstName = "Riff", LastName = "Raff" } and then go ahead and access x.FirstName and x.LastName, I can't declare a method signature like this: void Display({ string FirstName, string LastName } nameRecord) { } This is the kind of thing which is being proposed (along with possible pattern matching/decomposition syntax which is new ground for C#)

coldtea 12y ago

If only the open source languages we use had that many resources and paid developers... (Well, technically C# and the related libs are fully OSS now too, IIRC).

pherocity_ 12y ago
They are including almost all the frameworks you would use as well. They weren't set up to take pull requests, and I suspect that they're only interested in bug fixes. So, not entirely genuine.
antics 12y ago
C# isn't "technically" open source, it's just open source. If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here: https://github.com/dotnet/corefx/wiki/Contributing https://github.com/dotnet/corefx/wiki/Contributing
- coldtea 12y ago
  IIRC, they (MS) said would steer the language and .NET libs, and not involve a community style effort (because they want to ensure compatibility for their customers), did they change that?
  - jacquesm 12y ago
    Of course they would, it's their project after all. So you can contribute but with that in mind, it's about as open as any corporation is going to be when it comes to accepting input from the world at large. At least they got that bit right.
  - MichaelGG 12y ago
    That's not different than some open source projects and has no bearing on it being open source. Some project leads call attempted contributors idiots and refuse to even fix security bugs. Some have differing visions for their project. Which projects run by a strict vote, and how would you even decide who gets to vote? Most likely you'd elect leaders that will vote in the benefit of the project... Which is what MS has effectively done.

Rapzid 12y ago

I would LOVE for C# to get language support for go style channels complete with select and friends. C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~ And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by about 40% :| It feels like in theory it should be compiled down to code with the same efficiency? This is probably more of a CLR/JIT issue though?

radicalbyte 12y ago
40% is nothing, the last time I tested jquery.each vs a for loop, the for loop was at least 50x faster.
Cakez0r 12y ago
You can already get a long way towards channels by using reactive extensions (E.G. http://pastebin.com/h1xteunX http://pastebin.com/h1xteunX) Some syntactic sugar a la await could be nice though.
- theflagbug 12y ago
  Not sure if you're aware, but your Rx example has a few problems: 1.) In the StartSenders method, you're violating the Rx grammar by calling channel.OnNext concurrently. Wrap it on a lock statement. 2) In StartReceiver you're missing out messages the way you handle the channel. Replace the loop with a call to channel.Subscribe
  - Cakez0r 12y ago
    I did not know either of those things! Thanks!
rjbwork 12y ago
If you mean what I think you mean by "manually currying", it's likely because behind the scenes, there is a proxy class created for most (all?) lambdas that contains everything it needs to execute, including any scope variables maintained. So there's some extra overhead there, though not as much as you'd expect since everything, even value types, are pulled in by reference in the context of lambdas.

jpgvm 12y ago

If even 50% of this makes it into C# it's going to be a pretty amazing language. Native code interfaces were already reasonably fast, allowing more no copy semantics and array slice behaviour is going to do wonders for native library performance.

Cakez0r 12y ago
I really hope they implement this. It would make IO so much more efficient if you could pin a big chunk of memory and allocate buffers from it.

vans 12y ago

I think it's too late for non null ref types. But pattern matching, traits and built in code contract would be awesome !

ColinDabritz 12y ago
Non-nullable reference types have been called an impossible problem, but so was 'Await in catch and finally blocks' which shipped in C# 6. From http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-features-in-c-6.aspx http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-fea... "Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all." I'm hoping this is one of those 'Clark's first law' situations: http://en.wikipedia.org/wiki/Clarke's_three_laws http://en.wikipedia.org/wiki/Clarke's_three_laws 'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.' They've got quite a lot of smart folks working on C#, and it's heartening to me to see them taking another look at non-nullable reference types.
- pbz 12y ago
  It would be such an important feature that I'd be willing to tolerate breaking changes -- the language designers may not however.

mhomde 12y ago

I've been trying to think of something that drastically change how I coded. Bugs and productivity really are the two major dragons to slay. I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre conditions etc would really make things cleaner. Current implementation feels like it requires too much setup with separate classes, duplicate method signatures in several places etc etc. It would be really cool to have something like public int SomeMethod(int a, int b) pre { Requires (a > 5); Requires (b >= 0, new Exception("something something")); } { // DoStuffHere } post { Ensures (result > 0, new Exception("needs to be above 0")); } I'd even want to be able to separate it into separate files using partial classes (or something) so you could the condition stuff separate , with or without duplicating signature depending if you wanted to target specific overloads Full signature would simply be without the body: public int SomeMethod(int a, int b) pre { Requires (a > 5); Requires (b >= 0 ,new Exception("something something")); } post { Ensures (result > 0); } Without signature is trickier, but would be cool since you could use same conditions for several overloads, and just target the variables that are included in each: Conditions.SomeMethod { pre { Requires (a > 5); Requires (b >= 0, new Exception("something something")); } post { Ensures (result > 0); } } heck, why not even throw in "test blocks" and Visual studio could run light-weight kind of unit test as you programmed and mark the whole method as functioning or not. Imagine having a sort method and throw in something like: public IEnumerable<int> Sort (IEnumerable<int> list, Order order) test { (list = {3,5,6,2}, order = Order.Ascending) => result == {2,3,5,6}; (list = {3,5,6,2}, order = Order.Descending) => result == {6,5,3,2} } VS could highlight the failed test(s) directly in the editor as you coded The specifics and syntaxes of these things requires some thought but I love the basic premise, am I rambling? edit: I saw that something in this direction if not as extensive was actually discussed

pjmlp 12y ago
You kind of used D's syntax for contracts, http://dlang.org/contracts.html http://dlang.org/contracts.html

bartwe 12y ago

I'd like some method to write GC-less code for games. Structs with copy constructors and destructors perhaps.

talles 12y ago

> Method contracts Oh god, I want it SO BAD.

DrDimension 12y ago

I cannot help but think that the overwhelming desire to support immutability and functional constructs here, as well as in nearly all other modern languages, gives significant evidence that functional programming is finally winning out over OOP. In the future, I hope that FP will be the default design choice, with objects being used where needed such as for components, plug-ins, and ad-hoc dictionary-passing-style tools. After all, simplicity is the most important property of any software system - http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

noblethrasher 12y ago
Immutability was never incompatible with OOP, just the opposite in fact. Even Alan Kay often criticized languages like C++ and Java for encouraging the use of setters and, thus, “turning objects back into data structures”. C# is still one of my favorite languages (even though I use F# most of the time now), but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; it's too bad that fact was lost on so many programmers. Kudos for sharing the Rich Hickey video; it's one of my favorites of all time.
- azth 12y ago
  > but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.
  - noblethrasher 12y ago
    You have to go through the extra ceremony of writing a setter.
    - azth 12y ago
      The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void bar() { this.x += 1; // Whoops! } } Foo x = new Foo(); x.bar(); // Mutating call. Which Java does not prevent.