What’s New in C# 7.0

Post by voltagex_ » Thu, Aug 25, 2016, 5:38 AM UTC

flukus wrote: post #106

voltagex_ wrote: post #103

Earlier quoted context omitted.

Can you give an example of how C# would be different with anonymous classes? Googling that term just gives a whole lot of references to inner classes in Java.

One I've come across is binding a command to a button. With anonymous inner classes you can have something like: myButton.AddListener(new Command { bool enabled() { return false; //more logic goes here } void onClick() { //do something } });

Post by adwn » Thu, Aug 25, 2016, 5:45 AM UTC

MichaelGG wrote: post #86

manigandham wrote: post #46

Earlier quoted context omitted.

Every language has something missing, but C# has plenty of other great features so tuples weren't really that big of a problem. There are also plenty of built-in containers like the Tuple class that can offer the same functionality.

A tuple struct fills nearly zero of the real use cases for language level tuples. No pattern matching makes it sort of useless.

Post by douche » Thu, Aug 25, 2016, 5:56 AM UTC

mhomde wrote: post #33

flukus wrote: post #2

Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release. It's great to finally have tuples, but the c/java style syntax is showing it's age compared to something like scala which has return type declarations at the end, which I find much more readable. Literal improvements will be a godsend for writing database migrations. Ref returns and locals look li…

Yeah, I think lots of uses of out in the .Net framework are from the early days and a little bit of a mistake. Since they can't remove them this is suppose to make them easier to work with. TryGetValue comes to mind, but I agree overall out variables always felt clunky

Post by douche » Thu, Aug 25, 2016, 6:00 AM UTC

addicted wrote: post #105

dleslie wrote: post #7

It looks like they've added a lot of rope to hang ourselves with typos. int myvar, I; foo(out int mvar); // oops, not myvar; maybe caused by a refactor? bar(out *); // oops, not I; was up too late coding And so on. Things like this would be easily missed when reading code at-a-glance, and it's this sort of bug that arises often in languages that allow implicit declaration of variants.

The first one requires 2 errors. Reinitializing a variable (if you intended to use myvar then you wouldn't need to put int after your out) and compounding it with a misspelling. This is no different from how you'd make the same mistake today. I'm not happy about wild cards. It seems like taking what is a very powerful character in software development and using it for a pretty minor usability improvement. Besides it…

Post by edgyswingset » Thu, Aug 25, 2016, 6:07 AM UTC

platz wrote: post #94

edgyswingset wrote: post #36

Earlier quoted context omitted.

"Full" pattern matching, as one would expect from F# for example, wouldn't be something I could expect from C#. For example: type Tree = Empty | Node of 'a * Tree * Tree There is no way to express this directly in C#. Thus, I am "locked out" of a whole class of Pattern Matching that I would get with F#. But that doesn't mean that C#-style pattern matching (really, Is-patterns and a Type Switch) don't fall under the u…

> C#, is every bit a form of pattern matching as matching on a particular case of a union type. I'm afraid that is not the case, because in the current C# version, the compiler does nothing help you determine if you've matched all the possibilities. (it is not exhaustive) Exhaustiveness is important because it gives warning or an error to help you refactor and modify code without fear of breaking other code. Why enga…