
C# 7.0 – What to Expect - chachram
http://www.dotnetcurry.com/csharp/1286/csharp-7-new-expected-features
======
dodyg
This article is out of date.

Feature such as With expression has been pushed to version 7+. They have also
trim down the ambition of pattern matching for c# 7.

The best way to keep track of C# 7 feature is through their public roadmap
[https://github.com/dotnet/roslyn/blob/master/docs/Language%2...](https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md)

------
vmarsy
The feature below amazing, I wonder how Visual studio will display it, I like
it when above Properties it adds the ref count across the Solution:

    
    
          3 references
          public int Damage { get; }
          4 references
          public int Durability { get; }
    
    
    
      public class Sword(int Damage, int Durability);
      

This single line will result in a fully functional class:

    
    
      public class Sword : IEquatable<Sword>
      {
          public int Damage { get; }
          public int Durability { get; }
       
          public Sword(int Damage, int Durability)
          {
              this.Damage = Damage;
              this.Durability = Durability;
          }
       
          public bool Equals(Sword other)
          {
              return Equals(Damage, other.Damage) && Equals(Durability, other.Durability);
          }
       
          public override bool Equals(object other)
          {
              return (other as Sword)?.Equals(this) == true;
          }
       
          public override int GetHashCode()
          {
              return (Damage.GetHashCode() * 17 + Durability.GetHashCode())
                  .GetValueOrDefault();
          }
       
          public static void operator is(Sword self, out int Damage, out int Durability)
          {
              Damage = self.Damage;
              Durability = self.Durability;
          }
       
          public Sword With(int Damage = this.Damage, int Durability = this.Durability) => 
              new Sword(Damage, Durability);
      }

------
danielvf
C# continues its tradition of stealing the good stuff from other languages.
I'm really impressed. Pattern matching and immutable objects? This is great!

~~~
matthewwarren
It doesn't always steal, AFAIK is was the first language to introduce "async"
and the compiler magic that goes with it, i.e. so you don't have to use
callbacks everywhere.

~~~
PeCaN
Alice ML¹ had that in 2000², and the idea of promises/futures dates back to
the 70s. async/await to flatten promise hierarchies is decidedly _not_ a new
idea.

¹ [http://www.ps.uni-saarland.de/alice/manual/futures.html](http://www.ps.uni-
saarland.de/alice/manual/futures.html)

² Well, it used "spawn" instead of "await". The semantics are very similar
though.

~~~
Const-me
The innovation was to combine async/await to flatten promise hierarchies with
asynchronous callback-based IO under the hood to implement those promises
without using background threads.

That was the new idea that suddenly made those decades-old promises useful for
the software industry, as it allowed both blocking-style code simplicity and
callbacks-style IO scalability.

The ML link says “evaluates the expression exp in a new thread and returns
immediately with a future of its result” which translates to “not scalable”.

~~~
PeCaN
Alice ML “threads” are more like Erlang threads than C# threads. They're
lightweight userspace threads and you can have thousands of them. That's quite
scalable.

Also, that's not a new idea. Blocking-style code with async I/O scaling was
pioneered by Oz in 1991. (It did it a little bit differently from Alice ML.)

~~~
Const-me
“They're lightweight userspace threads and you can have thousands of them.” —
can I use 1000 lightweight userspace threads to run 1000 concurrent kernel-
space IO operations on files or sockets, one thread each?

~~~
PeCaN
Yes, that's precisely the point.

~~~
Const-me
MS implemented IOCP in Windows NT in 1994, then BSD implemented kqueue in
2000, then Linux implemented epoll in 2002 (they all functionally very
similar).

That means outside Windows, asynchronous event-based IO was only possible
after 2002 (that’s when the first version of libevent was released).

And yet you’re telling me the ML threads in 2000 were capable of high-
performance async IO? You sure about that? In 2000, which kernel API you think
that runtime used for IO?

~~~
PeCaN
Yes, and VMS had asynchronous system traps for I/O in 1977.² ³

And yes, of course? Erlang could do scalable async I/O in 1988.

Alice ML and Erlang both emulate async I/O by having a few OS level threads
each switching between a large number of userspace/VM threads. They queue I/O
operations then preempt VM threads when results are ready. For a while that
was the only sane way around the clusterfuck that is async I/O on *nix. It
still scales fine and I think there's rather little interest in converting
either Alice ML or Erlang to libevent/libev/libuv.

¹ The initial Erlang VM was very slow, but the I/O model was there. BEAM was
created in 1992 and was fast enough for Ericsson to use in production.

² NT and VMS were both designed by David Cutler, who is more or less the
father of asynchronous I/O at the OS level.

³ Incidentally, if you think async I/O in 1977 was advanced, you should look
at AS/400 or VOS sometime.

~~~
Const-me
> It still scales fine

Only 1024 sockets per select because FD_SETSIZE constant? How’s that scales
fine? You have 10k sockets = you need 10 native threads, with 10 native
stacks, on a quad code machine each of them is guaranteed to be out of CPU
cache when IO completes. Not fine, very inefficient.

> there's rather little interest in converting either Alice ML or Erlang to
> libevent/libev/libuv.

Well, Erlang developers don’t care about windows. And for BSD, Linux and
Solaris they already support native event-based async IO for many years. They
call the feature “kernel poll”.

> if you think async I/O in 1977 was advanced

I aware on some systems it was widely used. Just not on the mainstream *nix
systems where that Alice ML ran in 2000.

------
algorithmsRcool
Amoungst other things, this article covers Pattern Matching, Record Types and
Non-Nullable Reference types. All of which are great features but all of which
will likely not be in C# 7 unfortunately due to shipping timelines [0].

0:
[https://github.com/dotnet/roslyn/blob/master/docs/Language%2...](https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md)

------
jmartinpetersen
Object orientation and pattern matching is not an obvious mix. A lot of OO is
about dependency inversion, which is more or less the exact opposite of what
pattern matching gives you. It can be a powerful tool in the right hands but
could also lead to absolute horror. Sometimes it feels like Mads and co. are
too focused on making C# functional-like and in the process encourages a lot
of foot-shooting.

~~~
ahartman00
"Sometimes it feels like Mads and co. are too focused on making C# functional-
like and in the process encourages a lot of foot-shooting"

I agree. When they added dynamic and functional concepts, I though: great, a
dynamic/statically typed imperative/functional oo language. Too many different
ways to do things, makes it harder to understand code written in a different
style. Basically the opposite of python's "pythonic way" idiomatic style.

I do love functional programming, which is why I am trying to move to f#.
People at work are open to the idea!!

------
greenspot
Since I haven't see many new Windows apps the recent years, who is actively
developing new apps in C# and if yes, what kind of apps, which platforms,
etc.? Is it mainly games?

~~~
pjmlp
.NET has won the war over the desktop in what concerns native applications for
Windows on the big corporations.

On all enterprise customers that we work with, think DAX, if the application
is to run native on the desktop, which is usually means Windows workstations,
the software stack tends to be .NET with some C++ here and there.

Sun never managed to understand the desktop and Oracle even less.

So unless the customer has requirements for portable desktop applications, the
solution is .NET.

~~~
greenspot
Totally clear that mainstream desktop is Windows, native and .NET but the
question again and since there are rarely new apps on Windows: who is actively
developing new desktop apps in C#, .NET on Windows which are not games?

~~~
coldtea
> _who is actively developing new desktop apps in C#, .NET on Windows which
> are not games?_

Almost everybody doing in-house enterprise desktop apps (and those are a heck
of a lot) and tons of people doing desktop Windows apps that don't need to be
C++ (e.g. not Photoshop, Office and co).

Again, those are in the tens or hundreds of thousands. Check any Windows app
review site or repo for examples.

------
algorithmsRcool
In addition to the new language features there are some very exciting new APIs
being designed at:
[https://github.com/dotnet/corefxlab](https://github.com/dotnet/corefxlab)

Including a new higher performance/lower allocation text formatting API:
[https://github.com/dotnet/corefxlab/wiki/System.Text.Formatt...](https://github.com/dotnet/corefxlab/wiki/System.Text.Formatting)

------
srean
No biggie, but I do miss rotate, partition, nth_element from STL. Its just
that when I came to C# i came with an expectation that it would have all of
STL covered and more.

------
recursive
I'm curious how array slicing is any different from ArraySegment<T>, which is
very old.

~~~
algorithmsRcool
ArraySegment<T> is just a array reference with range delimiters. Slice/Span
gives you a low overhead, type safe window into a block of memory that can be
reinterpreted without allocating new memory. It's implementation involves some
IL level pointer hacks to keep it fast.

Joe Duffy's first implmentation of it is here:
[https://github.com/joeduffy/slice.net](https://github.com/joeduffy/slice.net)

The more recent work for CoreFX is here:
[https://github.com/dotnet/corefxlab/tree/master/src/System.S...](https://github.com/dotnet/corefxlab/tree/master/src/System.Slices)

~~~
premium-concern
So instead of improving the implementation of ArraySegment they just add yet
another way of doing it?

This is of course expected for languages which keep piling up stuff but still
disappointing.

~~~
pjmlp
Because of backwards compatibility.

~~~
premium-concern
How is that impacted by a faster implementation technique?

Are you arguing that some people rely on ArraySegment being slow?

~~~
pjmlp
No, it isn't compatible with any of the existing APIs that accept array or
strings.

So making it compatible would probably require breaking its semantics.

------
rco8786
C# is basically becoming Scala

~~~
steego
Minus the type system that is itself Turing complete.

In all seriousness, the culture behind C# is way too conservative for it to
ever to become like Scala. They add features, but they're nowhere near as bold
and daring as the Scala team. As a language, Scala's is both incredibly
impressive and terrifying from an Abstraction Astronaut's perspective. Even F#
is very conservative compared to Scala.

~~~
algorithmsRcool
I had a lot of hope for some wilder C# changes with the .Net core change. But
i see a lot of hold back from established codebases. I almost wish we could
fork the language to target the Java-esque crowd and the Go/Swift/Scala crowd.

