Hacker News Reader

Comment by mintplant | Hacker News Reader

Pattern matching! Tuples! Awesome, C# 7.0 is scratching two itches I've felt every time I've worked with it.

If only .NET had a suitable cross-platform UI toolkit, then I'd be using it everywhere. Eto.Forms is a good attempt but I found rather buggy and limited at this point in development. Avalonia, while further along in terms of stability and features, doesn't even try to fit in with any platform's look and feel.

View on HN

Very glad to see tuples and pattern matching also. But allowing the tuples to be structs with mutable public fields seems off. Once a tuple is constructed it shouldn't be mutable IMO, unless I'm missing some important use cases?

Quick'n'dirty construction of custom mutable trees, I guess? Don't know about important. Best guess I have.

This is the feature I've been waiting for!

Correct me if I'm too excited, but won't these be an excellent alternative to maintaining lots of DTOs for SQL calls?

I was thinking the same, I never really liked having those, also good for handling responses from services.

Why not winforms? Very convenient, and mostly works in mono

WinForms is a dead end. It doesn't support Windows modern or Mac OS X, and it looks completely out of place on Linux.

> It doesn't support Windows modern

That's a good thing.

> or Mac OS X

"Does Winforms run on OSX?

Yes, as of Mono 1.9, Winforms has a native OSX driver that it uses by default"

http://www.mono-project.com/docs/faq/winforms/

> it looks completely out of place on Linux

On KDE3? KDE4? KDE Plasma? Gnome2? Gnome3? MATE? Cinnamon? LXDE? LXQt? Xfce? CDE? GnuStep? Unity? Enlightenment? Non-DE X Window System environment - with which Window Manager, with which theme?

Going by the documentation you linked yourself:

> In terms of integrating visually with the desktop, we currently ship with a classic Win32 theme.

That sticks out like a sore thumb everywhere, including every Win32 release since Windows 2000.

The standard Win32 theme is the classic, an engineering marvel. Everything else that came after that - starting with the infamous native Windows XP theme - was and is a horrible mess.

I'm pretty sure that it looks out of place in all of the Deskktop environments that you have mentioned.

On Windows it takes the style of whatever window theme you're using, what do you mean?

"mostly works" is rather… optimistic.

Feels kinda crazy to see tuples and pattern matching "just arrive" when other languages have had them for years.

What's your bar for "other language"? Remember that C# is a mainstream language, with all that entails in terms of stability and conservatism of language design (and the other way around - it's popular partly because it's conservative). Comparable languages are Java, C++ and the like; and in that category, C# is, generally speaking, more on the "progressive" end of the spectrum. Comparing it to something like Scala is rather apples and oranges.

A big advantage of this design over most of the other languages with tuples that I've seen is that their members can have names - that is, types can be anonymous but have named members. This I think hits a sweet spot as it's rare to not want fields to have names, but fairly common to want intermediate types that just bundle a few fields together where there's no good name that clarifies much.

Anonymous items with named fields are always only just one name away from being structs. That seems to me to be the least-sweet spot in the possibilities of (named/anonymous item) x (named/anonymous fields).

It's a very big step in a language with nominal typing. Tuples with named fields are compatible (even across assemblies, if I remember correctly) so long as order, names and types match. Structs are not compatible in that manner.

Nice point. There's also the fact that with deconstruction being added as well, you don't even have to have the overhead of declaring a struct variable to get the return value and then dereferencing the fields, you can just deconstruct the tuple into variable if you so wish.

> Anonymous items with named fields are always only just one name away from being structs.

That's a huge line to cross though! Once you give it a name then you generally have to give it a home somewhere.

Out variables, and I imagine the various sorts of tuples, are created on the stack. Structs can by stack-allocated, or they can be heap-allocated, which has performance considerations which may be important in a given program. This feels much more like a case of right tool for the job than anything else.

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.

Exactly. The biggest that comes to my mind is generics which are missing from many languages.

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

What about returning multiple values from a function without declaring a dedicated type? That is pretty useful.

Sure. Like how streams "just arrived" in Java yet C# has had the equivalent for years.

No language has every feature. C# is making enormous strides ahead of many of its counterparts.

Java's a pretty extreme outlier for late or non-adoption of modern features, but it is true that Java is the closest direct competitor/peer to C# in terms of usage/marketshare. C# seems to be steadily shifting from being a language which initially (v1.0) looked like Java to one which looks increasingly like Scala (e.g. addition of pattern matching, tuples, local methods etc.).

Java is generally C#'s main competitor. Comparing them is the most appropriate comparison.

Scala seems to be vastly more expressive while simultaneously having only 20% of C#'s feature set.

F# would probably be a better comparison peer to Scala than C# would IMHO

There was always the Tuple class you could use since .Net 4.

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.1...

There's a few downsides to the Tuple class as mentioned here: https://github.com/dotnet/roslyn/issues/347

Namely, heap allocation and the inability to name tuple members.

And a very verbose syntax. You have to repeat everywhere the different types of the different members.

Tuple.Create(3, "hello", true)

Type inference FTW.

I find that the verbosity can be minimised by type aliasing. E.g:

using Complex = System.Tuple<double, double>;

Edit: Clarity

But then you might as well declare a class or structure to store the data. The point of tuples is to be self-contained.

It maybe wasn't clear, but I was referring to the parent's point about verbosity when using the 'old' Tuple class.

    using Complex = System.Tuple<double, double>;

is less verbose than

    public class Complex
    {
        public double i { get; set; }
        public double j { get; set; }
    }

Not quite equivalent, since System.Tuple is immutable. So, at minimum:

  public class Complex {
    private readonly double _i;
    private readonly double _j;
    public double I {get {return _i;}}
    public double J {get{return _j;}}
    public Complex(double i, double j){
      _i = i;
      _j = j;
    }
  }

But System.Tuple is also IComparable, IStructuralComparable, IStructuralEquatable. I haven't had enough coffee yet to add all the boilerplate for that to the above, which only reinforces the point about verbosity.

Although with c# 6.0 (current release) you can simplify that to:

  public class Complex {
    public double I { get; } 
    public double J { get; }
    public Complex(double i, double j) {
      I = i;
      J = j;
    }
  }

Even before C# 6.0, you could simplify it this way:

  public class Complex {
    public double I { get; private set; } 
    public double J { get; private set; }
    public Complex(double i, double j) {
      I = i;
      J = j;
    }
  }

Reply on news.ycombinator.com