
.NET Framework – What's New in C# 7.0 - kukx
https://msdn.microsoft.com/magazine/mt790184
======
zilchers
Is it just me, or is C# basically becoming Scala (or, insert your favorite
functional language here). Don't get me wrong, this is awesome, .net on Linux,
dockerized, is all good, but these moves definitely show Microsoft responding
to market changes in a way they didn't used to.

~~~
stupidcar
C# first introduced lambdas and LINQ in v3, back in 2007. It was the first
mainstream OO language to really push a more functional/mixed-paradigm
approach.

This is definitely an area where Microsoft has lead the market, not followed
it.

~~~
louthy
They may have been the first, and LINQ was (and is) a truly great feature (I'd
love it if they'd expand the grammar, or allow computation expressions like
F#); but the problem I've found with trying to do functional programming in C#
is that there's no BCL support. Whereas F# has its functional _prelude_.

I haven't spent much time with Scala, but I get the impression that a lot of
the functional stuff is there by default (or at least easily accessibly via
Scalaz) and therefore less inertia is needed to write functionally in Scala.
Even with LINQ most C# programmers think it's just for querying databases or
XML files, they don't realise they have built in monad semantics.

I found that I'd have an immutable collections library _over there_ , that
wasn't aware of the Option type in _that library over there_. (So
Map.Find(key) couldn't return an Option<V> for example - this makes
composition more difficult).

So although the language has been steadily going in the right direction, there
has been less of a concerted effort on the library front. And therefore C# is
still behind IMHO.

This is something I've been trying to rectify, by essentially building a
functional BCL [1]. I welcome the increased pace of functional features
recently. Although sometimes it's frustrating seeing the direction they're
going and wishing they'd get there much quicker (expressions everywhere, sum-
types, record-types, better type inference).

It's interesting that often C# is held up for its inability to do type-classes
or ad-hoc polymorphism. But it is in fact possible with C# today [2] [3], and
with zero cost (i.e. no reflection, additional memory allocations, or side-
stepping of the type-system). It just causes a massive head-ache of manually
provided generic arguments... [4] [5] I'd love it if the Roslyn team took some
time to deal with the generic parameters inference story. It would help bring
ad-hoc polymorphic types to C#, but it would just be awesome in general.

[1] [https://github.com/louthy/language-
ext](https://github.com/louthy/language-ext)

[2] [https://github.com/louthy/language-ext/blob/type-
classes/Lan...](https://github.com/louthy/language-ext/blob/type-
classes/LanguageExt.Tests/TypeClassMonad.cs)

[3] [https://github.com/louthy/language-ext/blob/type-
classes/Lan...](https://github.com/louthy/language-ext/blob/type-
classes/LanguageExt.Tests/TypeClassMonoid.cs)

[4] [https://github.com/louthy/language-ext/blob/type-
classes/Lan...](https://github.com/louthy/language-ext/blob/type-
classes/LanguageExt.Core/TypeClasses/Monad/Monad.Prelude.cs#L70)

[5] [https://github.com/louthy/language-ext/blob/type-
classes/Lan...](https://github.com/louthy/language-ext/blob/type-
classes/LanguageExt.Core/DataTypes/Option/Option.cs#L780)

~~~
int_19h
A big problem wrt speed of evolution of NET historically has been the legacy
design of the BCL, and the fact that it's updated as one monolithic thing when
a new .NET version is released.

The new model used by .NET Core is to make everything a NuGet package; and not
a single big one, but small packages comprising one particular bit of
functionality, each of which can then be versioned separately. For example,
collections are a NuGet package:

[https://www.nuget.org/packages/System.Collections/](https://www.nuget.org/packages/System.Collections/)

With this model, it's possible to iterate on the API much faster, so my
expectation would be to see functional APIs in the standard library spread
much faster from now on.

~~~
ygra
Interestingly they thus have effectively an equivalent of Java's long-awaited
and long-postponed Project Jigsaw. It seems to not have been such a roadblock
for MS, maybe also because of a somewhat shorter history of the platform (no
idea how comparable the code inside is regarding spaghetti-ness and
interdependencies).

~~~
oblio
I think it's more due to Sun dropping the ball and Oracle not putting the same
amount of resources behind Java as Microsoft puts behind .NET.

------
louthy
Throw expressions are particularly welcome. I'd previously dealt with that
issue by creating a static method that returned the expected type, but just
threw an exception [1][2]

I'm not sure it's explicit in the blog, but it seems the deconstructor will be
useful for pattern-matching using 'is'.

Tuples. Yay! Finally!

Pattern-matching-switch-statement: Not an expression. That's a bad call. We
have expression based ternary, throws, method bodies, and LINQ; switches are
the last and most painful omission.

Local functions: Fantastic for libraries like mine, which is trying to bring
functional programming to the C# world, but takes a hit with the allocation of
delegates for common operations [3] It should be a boon for anything LINQ
based (implementations, rather than usage).

Return by ref and out parameters: I'd be happy if they just removed them from
the language. Ugly, error magnets.

All in all, good progress. Hopefully they can make more progress on
facilitating expression-based programming, and bring in record types for the
next release. The pain of creating immutable types is truly tedious. And I'd
desperately like to see partial generic parameter specifying (for when one of
the generic arguments can't be inferred by the type-system, so you then end up
having to specify them all).

[1] [https://github.com/louthy/language-
ext/blob/master/LanguageE...](https://github.com/louthy/language-
ext/blob/master/LanguageExt.Core/Prelude.cs#L209)

[2] [https://github.com/louthy/language-
ext/blob/master/LanguageE...](https://github.com/louthy/language-
ext/blob/master/LanguageExt.Core/Prelude.cs#L182)

[3] [https://github.com/louthy/language-ext/blob/type-
classes/Lan...](https://github.com/louthy/language-ext/blob/type-
classes/LanguageExt.Core/TypeClasses/Monad/Monad.Prelude.cs#L70)

~~~
snarfy
Of all the new features, ref return leaves me scratching my head. I agree ref
and out should go away. Adding more support for ref will only increase its
usage when it should be deprecated.

~~~
int_19h
It shouldn't be deprecated any more so than "unsafe" and "stackalloc". It's a
great advanced tool for perf-sensitive code - not something you should reach
by default, but something to keep in mind when firing up that profiler.

CLR supported the concept since 1.0. Surfacing it in C# has been long overdue,
and makes it possible to write more low-level stuff without having to go to
C++.

------
batina
Pattern Matching with Is Expressions

Awesome! Greatly reduces "ugly" boilerplate code like this:

    
    
        if (control is TextBox)
        {
            var textBox = (TextBox)control;
            textBox...
        }
    

Also, it would be great if Microsoft could make full properties in another way
so that you do not have to write a backing field for it. Something like this:

    
    
        public string LastName
        {
            get;
            set 
            {
                if (value == "Batina")
                    RaisePropertyChanged();
            }
        }
    

It would make code more cleaner.

~~~
jsingleton
I think if you're writing property accessors manually then there should be an
explicit private backing field. Otherwise there is just too much magic going
on.

Normal auto-implemented properties are fine:

    
    
      public string LastName {get; set;}
    

As are read-only ones:

    
    
      public string LastName {get; private set;}
    

Yet, I feel that if you are writing logic in there then you should fully
control it. Or else there is too much being done that is non-obvious and could
cause problems down the line (for others or your future self).

However, they might be able to achieve something with data annotations that
wouldn't be too magic. For example:

    
    
      [RaisePropertyChanged("Batina")]
      public string LastName {get; set;}
    

Tip: In VS you can just type "prop" then press tab to auto-generate the code
for a class property. You can then easily auto-change this to a fully
implemented version. This also works for "for" and "foreach" loops etc.

I haven't done much Java in a while but do you still have to write out all of
your property accessors fully? Might not be too bad if the IDE can generate
this code.

~~~
batina
I don't think its possible with data annotations because there will me more
complex logic in setter then I described.

I would just like to see _get_ working like in auto-implemented property
(without backing field) but setter to be manually implemented (with value
keyword).

Also you can use _propfull_ snippet for full property implementation.

------
netcraft
So, lets say someone had never worked with C# or .net before and works on a
mac - where would you go to get started building a small server application? I
assume you would use the .net core stuff? and visual studio code? Any good
tutorials for noob-to-the-ecosystem but someone that has programming
experience?

~~~
merb
> [https://www.visualstudio.com/vs/visual-studio-
> mac/](https://www.visualstudio.com/vs/visual-studio-mac/)

It bundles everything you need. And for the tutorial you can check links from
other people.

------
JamesBarney
Kinda surprised me Microsoft doesn't have better syntax highlighting on msdn.

The lack of coloration and gray background gave me a little bit of a headache.

~~~
msbarnett
Coupled with the wrapping, paucity of line breaks, and (near lack of)
indentation, the examples are damn near unreadable.

------
zamalek
I'm very disappointed that ref returns were not implemented as syntactic sugar
for out params.

A bit of history: game developers have been crying for a solution to the
matrix operator problem. A 4x4 matrix is 64 bytes of data. Implement the
mathematical operators using C# operators and you're looking at 192 bytes
copied per invocation. The workaround is the fake ref operator: void Add(ref
Matrix, ref Matrix, out Matrix). The problem is that this results in code
smell at the call sites. The ref return was the first compromise, allowing
that method to become: ref Matrix Add(...). The ultimate solution would be to
allow ref returns and ref parameters on operators, but you need ref returns
first.

This feature misses all of that. Maybe we'll get out returns, but the argument
against it would be language bloat, and even I'd agree. _Sigh._

/rant

~~~
kukx
The Add method signature could be simplified from void Add(ref Matrix, ref
Matrix, out Matrix) to Matrix Add(ref Matrix, ref Matrix).

Also, could you elaborate what you mean by out returns? Normal returns could
be considered "out returns", no?

~~~
bad_user
If Matrix is a value type, then no, that's not the same thing, because with
"out Matrix" it is passing it by reference, instead of by value.

~~~
kukx
Isn't it in this case just an implementation detail without any meaningful
consequences (apart from interop)? - I'm trying to find a way to benefit from
it. I wrote some code to compare the two approaches and see what's going on
underneath.[0] I'm not familiar with IL, but it seems like the memory usage is
the same and the simple return function requires less ops.

[0]
[http://tryroslyn.azurewebsites.net/#f:>ilr/A4VwRgNglgxgBDCBD...](http://tryroslyn.azurewebsites.net/#f:>ilr/A4VwRgNglgxgBDCBDAziuBhOBvAUHAuUSWOFAFwCcQZy4BlHfQl46eKAOzoA0BuZgQC+gouHZwAbgHsoAEzgB5EOQAU0lQzgAPAJRMWLbXAC8cTgFMA7luxwepuAEY4QgSxGtxpRgCULavp4hoSUASCUnObWtvaOAByu7oSehGykMvJwALKqQaIsjNrJIcpqGnR6JYbGZv6B1SJCQA==)

~~~
zamalek
This is no implementation detail and has nothing to do with overall memory
use. It has to do with how much memory is _copied_ (an operation that consumes
time) per invocation. IL is the wrong level to look at this.

In the by-value case: a stack frame of 192 bytes is allocated (+ space for
other locals). The values of the matrices are copied into it from the parent
stack frame (128 bytes). The method does its work and then calls "new Matrix".
This occupies the final 64 bytes. Immediately this value is copied out of the
method to the parent stack frame.

In the by-ref case: a stack frame of 0 bytes is copied (+ space for other
locals). The pointers to the two matrices are passed in, as well as a pointer
to the memory for the result. The method does its work and then calls "new
Matrix". The result of the .ctor is stored directly in the calling stack
frame.

You might consider that this is nit-picking, but consider that this has to
happen 60 times per second. Calculating an MVP matrix for 1000 objects 60
times per second, results in 32MB of memory copied around per second. That
assumes you are doing no additional math (which is definitely _not_ the case).
The performance benefit is substantial enough that even XNA had these
overloads (which is where I think the workaround originated)[1].

[1]: [https://msdn.microsoft.com/en-
us/library/bb194950.aspx](https://msdn.microsoft.com/en-
us/library/bb194950.aspx)

------
markatkinson
It puts a smile on my beak that I am a budding (sort of) .Net and C#
developer. Microsoft seems to be really jacked up and introducing some very
forward thinking functionality into their ecosystem. Been playing with Azure
Service Fabric. It is super impressive.

~~~
xorxornop
Yeah, Service Fabric is super awesome! I'm refactoring out company's
infrastructure to run on it currently - the older stuff runs on MVC 5 on Azure
Cloud Service.

I'm refactoring it to ASP.NET Core on Service Fabric. Getting about 50x better
real-world performance. Yes, that much. It's insane. Currently on Windows as
Service Fabric on Linux is in preview (not comfortable using it in
production), but I imagine I'll move it over once that's stable ️

A great time to be a .NET developer! Makes me happy I stuck with it.

------
setq
I'm interested to see what the production story is for some of these language
features. I usually get left a festering minidump with a number of threads, a
pile of stacks and some line numbers if I'm lucky these days. It's quite hard
determining which dereference or call is the one that triggered the problem in
a method body with so many things now compacted into a tight expression.

Granted there should be assertions to prevent these conditions occurring but
not everyone on the team is perfect 100% of the time. Sometimes an edge case
slides in as well and you have to heavily assert everything and push to
test/production to reproduce which isn't ideal.

------
alexro
Are we back to the 90-ties with no code highlights in text?

~~~
jdmichal
The markup actually does have coloring. However, there's a CSS rule that's
overriding them all back to black. How strange.

~~~
redwards510
Yeah, I just came to say this. Here's the code, with obvious color markers.
[http://i.imgur.com/91dFyRr.png](http://i.imgur.com/91dFyRr.png)

~~~
redwards510
fix:

.codeSnippetContainer span { /* color: #000 !important; */ }

------
redwards510
Can someone give an example of a use case for a Deconstructor?

~~~
Leszek

        var (ret, err) = Foo();
        if (err != null) {
          ...
        }

~~~
taco_emoji
So Foo() has to return a class which has a destructor? Seems like just
returning a Tuple would be better in that case.

~~~
truncate
Tuple in C# is a class IIRC. Without destructor, you will have to pull out
individual members separately. For example for a tuple of form <Int, Int,
Int>, you will do something like `var r = c.getFirst(); var g =
c.getSecond();`. With deconstructor, you can do the same via `var (r, g, b) =
color;`. In other words, you can say that tuples are way to combine data,
while deconstructors tell how to explode it. Since these deconstructors are
themselves functions, you can do computation each time, and get different
results due to side-effects (probably not good idea).

EDIT: I don't know C#, so syntax is definitely not right.

~~~
EpicEng
You would just check t.Item2, no need to assign to variables I'm this example.
However, the deconstructor syntax is nice, and now tour functions don't all
return Tuple with vaguely named members.

~~~
truncate
Right. Not great example. What I wanted to say was deconstructor is all about
creating new bindings with nicer syntax. You could just do that by calling
getters / accessing fields, but you have to write more when you doing that.

~~~
EpicEng
Well, it allows you to return multiple objects without using an opaque Tuple
or creating your own class. Sure, the other options work, this is just a nicer
syntax. I mean, I can all of what C# does in C if I want to, but I appreciate
the syntactical sugar.

------
keithnz
more improvements that allows more concise code and that looks functional in
nature. Which is great, I have to do a lot in C# and really like it as a OO /
with functional abilities type language.

But I keep wondering why F# doesn't really take off given a lot of peoples
fascination with the functional world. It does functional nicely while still
being able to bridge back to the OO world which allows you to easily leverage
a __LARGE __amount of libraries in the .net world. It has a really good
community, and F# specific frameworks for various things as well. It 's like a
hidden gem that people pass over as they look at functional languages with
much much smaller ecosystems.

~~~
bad_user
I only played with F#, but my day job is writing FP code in Scala, so let me
answer this:

> _I keep wondering why F# doesn 't really take off given a lot of peoples
> fascination with the functional world_

As a matter of fact there aren't that many people interested in FP, mostly due
to a lack of education on the matter. Even many people talking about FP are
confused about what FP is. And the problem with the FP ecosystem are the
abstractions, which tend to be extremely high level and very productive,
however these aren't taught in school and the cost of entry is high.

So let me throw this question right back at you: _why F# and not Haskell?_ And
note that the answer you give is going to be applicable to C# versus F# and at
the same time flawed ;-)

And you see, raising the abstraction is one way humanity has always tackled
complexity, however this is essentially about vertical scalability of talent -
or in other words enabling the same people to handle more challenging problems
by giving them better tools. But the trouble is that this is incompatible with
horizontal scalability, which is about growing by hiring more and more people,
i.e. building assembly lines.

So going back to your question, the reason for why not FP is actually simple,
but hard to swallow: the software industry is growing due to huge demand, as a
consequence a majority of people working in this field are beginners and when
the industry has a choice between quality and quantity, it will go for
quantity at the expense of quality.

On the other hand the good news is that with the proper education, mindset and
tools, as a small team, you can still build products that compete with big
companies having virtually unlimited resources.

~~~
keithnz
why F# and not Haskell? Now we are leaving the .NET world. We are leaving a
lot of libraries behind that bridge to many many things. For instance, my
latest F# project was to make a REST service that bridged to a Digital I/O
board, the DIO board manufacturer has .net libraries for their devices, I
simply wrapped those, used Suave.io, 50 lines of code later I have a
webservice for control of DIOs. The point about why F# is really good is the
huge amount of libraries you get for free that very few other functional
languages enjoy ( JVM based languages would enjoy this advantage too ), you
can make bridges to other languages / environments, but that's not quite as
straightforward. So to me, it's not the same argument.... F# -> Haskell (lose
the libs) C# -> F# (don't lose the libs). Not only that, you can sprinkle it
into your projects before fully committing to it.

------
jdmichal
I'm a little disappointed that pattern matching doesn't simply narrow the
variable, and instead requires a new variable name to hold the narrowed type.
Even TypeScript narrows the variable in-place!

~~~
louthy
You may want to deconstruct the value _and_ use the original base value. This
seems entirely logical, and consistent with most implementations in functional
languages (and I'd say makes TypeScript's implementation the poor one -
although I haven't seen it myself to have an opinion on).

~~~
naasking
> You may want to deconstruct the value and use the original base value.

I think this is exactly right. Members can be declared visible only when
viewing an object through a particular supertype, and you may simultaneously
need to invoke methods from the supertype and the subtype.

------
muterad_murilax
Minor nitpick: the title is (edit: was) missing a leading dot.

------
duke360
major part of these new features are very cool but i'm afraid they could
compromise future evolution of the Language. some implementation details
scares me, maybe i'll become used to them, i only hope that these doesn't
result in a boomerang for future versions.

Deconstruction implementation is scary, i would prefer to have a special
symbol (like the desctrutor) and duples that ignores names are ok but sounds
very error prone, maybe i just have to try them to understand, also order
sensitive case makes my dev sense tingle...

------
gigatexal
I was a die-hard python guy and now I'm a die-hard python guy who appreciates
.Net. (Forced to because I work in a .Net shop, but it has chops)

------
bobcostas55
Why such a verbose syntax for pattern matching?

~~~
junkyarddog
It still has to look C#ish.

------
ryenus
Possible to use variable placeholders on the left side of a deconstructor
assignment?

~~~
mathw
There's a plan to allow wildcards in deconstruction patterns, but it doesn't
look like it's ready in time for C# 7. So hopefully that will appear in C# 8.

It would look something like:

var (first, second, *) = ReturnsFourThings(foo);

------
stuartd
'goto case' is a thing? I'm so going to have fun with that

~~~
int_19h
It has always been a thing. The original C# design was to take the C switch
statement as is, but tighten it up to avoid crazy stuff like Duff's device,
and to make non-obvious implicit things explicit.

Consequently, C# _requires_ that control flow provably cannot reach the end of
any non-empty case block (to avoid implicit fallthrough that normally happens
in C, Java etc). Normally this means that you _must_ use `break` (or something
else that transfers control, like `continue`, `throw` or `return`). But
fallthrough is actually useful sometimes, and `goto case` provides you with a
way to request it explicitly - and then ramps it power up a notch, because why
not?

Amusingly, this is something that C doesn't have, even though its case labels
are true labels (allowing for Duff's device and similar tricks). If you want
to goto them, you need to add an explicit named label there.

------
shaydoc
removal of pre-declaration of out parameters = win!

