News for hackers. Stuff that matters.
Re:More functional C# by insidenorm on Sunday January 12, 2014 @10:07PM (#7048665)
Re:More functional C# by mcgwiz on Sunday January 12, 2014 @11:31PM (#7048925)
Whitespace insensitivity and inability to return void in generic contexts are "critical flaws"?

Anyway, no one's saying C# is flawless. Personally, I would love the ability to declare immutable graph references.

Re:More functional C# by V-2 on Monday January 13, 2014 @04:51AM (#7049691)
http://hestia.typepad.com/flatlander/2012/01/action-func-voi...

I fail to see how it is an "obvious critical flaw" :)

   You have to create a separate overload that takes an Action instead of a Func, 
   and has an identical implementation except for omitting the return keyword.  
   Granted, that’s not much work for a simple helper like the above, 
   but what if it were more complicated?  
No, it's simply not true that you need "an identical implementation except for omitting the return keyword"...

Eg. this would do the trick without repeating the implementation: http://pastie.org/8628864

Just two one-line overloads as entry points.

Re:More functional C# by raphaelj on Monday January 13, 2014 @09:43AM (#7050778)
Your solution is at least as ugly as the one mentioned in the article.

The problem is that void can't be used as a regular type identifier.

In a lot of langages (like Python, Haskell, F#, ...) there is a regular type for void. This type is often implemented as such :

  sealed struct Void {
  }
Then you can define Action<...> just as Func<Void, ...>.

As the compiler is smart enough to see there is only one kind of Void value, it can be entierly removed from the generated code and thus doesn't make your code slower.

Re:More functional C# by V-2 on Monday January 13, 2014 @10:08AM (#7050938)
And quite what's so ugly about it? It's hackish, but once you create these overloads, you don't need to worry about it anymore and you can call the method just as if Func<T> could be casted to Action. I don't think it can even be compared to the one suggested in the article, since it does not require "creating a separate overload with an identical implementation" (!!!), potentially copy-pasting hundreds of lines of code if the method in question was indeed "more complicated". This is ridiculous and the fact the author couldn't think of a workaround that didn't involve it baffles me.