Hacker News Reader

Don't tell me you're not looking forward to seeing

  public static Dictionary<(long id, string firstName, string lastName), (string shippingAddress, DateTime date, List<(long itemId, string itemName, decimal price)> items)> LoadCustomerOrders()
  {
      // ...
  }

in your codebase :)

I think C#'s designers make it clear that they don't want you to use out parameters. They're a hack; they were only included at all to make it easier to communicate with C/C++ libraries. But now that they're there, they have to stay because of back-compat - Microsoft definitely does not want a Python 3 situation. They might as well make them as painless as possible for the people stuck with them because of some library. And at the same time, they should offer a compelling alternative to out parameters, which they have finally done with tuple returns.

I mentioned this in another thread, but I wish they'd tell the Visual Studio Team not to use them, then - The SOAP and WCF tools will still happily generate code that requires out parameters.

People still use WCF? I suffered enough getting one project running with Windows Configuration Fuckup. Never again.

Some of us are stuck using them as part of legacy systems. We're eliminating them as we move to a newer stack but legacy code can be quite sticky.

How can they be considered a hack when they get baked in the BCL in so many places as well, not for interop purpose?

Your ShapeHandler example above is an example of multiple dispatch[1] - something not very fashionable anymore, but which I'd love to see in a statically typed language. It's a more natural feature for an OO language - but I wonder about the trade offs it has with pattern matching and Algebraic Data Types.

[1] http://wiki.c2.com/?MultipleDispatch

FWIW you can abuse dynamic in C# to get multiple dispatch, although not with much static checking.

  using System;
  
  class Foo { }
  class Bar { }
  
  static class Program {
  	static void Example(Foo l, Foo r) { Console.WriteLine("Foo Foo"); }
  	static void Example(Foo l, Bar r) { Console.WriteLine("Foo Bar"); }
  	static void Example(Bar l, Foo r) { Console.WriteLine("Bar Foo"); }
  	static void Example(Bar l, Bar r) { Console.WriteLine("Bar Bar"); }
  
  	static object Create(string arg) { return arg == "Foo" ? (object)new Foo() : new Bar(); }
  
  	static void Main(string[] args) {
  		dynamic l = Create(args.Length > 0 ? args[0] : "Foo");
  		dynamic r = Create(args.Length > 1 ? args[1] : "Bar");
  		Example(l, r);
  	}
  }

I see your point on out parameters, they are ripe for abuse. You can abuse out parameters right now, just with a little more effort.

    var x, y;
    p.DoSomething(out x, out y);

Where this becomes useful, I think, are places where you can't avoid using an out parameter. Now, you can choose to throw away or use the out parameter without explicitly declaring it.

    var isNumber = Int32.TryParse(number, out x);

Option types are the way to go for something like this:

    public static class Parse
    {
        public static Option<int> TryInt(string str)
        {
            int value;
            return Int32.TryParse(str, out value)
                ? Some(value)
                : None;
        }
    }

    var x = Parse.Int("123").IfNone(0);

    var x = Parse.Int("456").Match(
                Some: x  => x * 2,
                None: () => 0
            );

    Parse.Int("456").Iter(Console.WriteLine);

https://github.com/louthy/language-ext/blob/e6ff382a1752c7de...