Hacker News Reader

Comment by hackinthebochs | Hacker News Reader

Your list basically boils down to "C# isn't <insert favorite language>". Which is fair of course, but most of your list wouldn't really make sense in C#.

View on HN

That's just not true.

All the suggestions on the list make sense, and many like them have been added over teh past few years. To me it seems that all of them except the 'reference types that are not nullable' one could be easily added without breaking backward compatibility.

In fact, I wouldn't be amazed if a C# 6 has sugar for tuples and destructuring assignments and the likes. It matches the language well (already got a type-inferencing compiler, already on the road to incorporating increasingly many functional programming ideas).

And, well, in code you can already say

    var george = new Person();

But in property and field definitions, you still have to say

    Person george = new Person();

How is allowing "var" there a turning "C# into a different language"? Nearly the entire list the GP mentions are fixes on this level of complexity.

The only reason I see for not doing things like this is to avoid becoming the next C++, in which there's just too many features and things to understand.

What you suggest could work, but I'm not sure how useful that would be in the end when you still have to declare the type for fields initialized in the constructor. The var keyword inside methods covers most cases of using variables. A "var" keyword on the field level would cover less than half of the cases. Plus, you'd have to add a new keyword to do it as "variable" doesn't quite fit the meaning. Just not sure how useful that is.

sugared tuples and destructuring doesn't really fit. You'd have to make special case syntax for it and it would just feel bolted on to the language. Plus, tuples lose their usefulness if you have to declare its type to pass it between methods.

Though his first point about getters and setters does make sense, I didn't quite comprehend it the first time around.

You'd have to make special case syntax for it and it would just feel bolted on to the language. Plus, tuples lose their usefulness if you have to declare its type to pass it between methods.

I think it could be OK even without return type inference on methods. Imagine you could type this:

  (int, bool) TryParse(string str) {
     // do stuff
     return (num, success);
  }

That would be clean enough.

I think you might be right about that one. That does look rather elegant. I was initially skeptical about creating a totally new language construct to create inline tuples, as (num, success) looks like it needs a new in front of it, which ruins the pattern of assignment for destructuring.

But once you get over that mental hump of seeing a new in front, it really starts to make a lot of sense. A tuple could be considered a value type and treated similarly to int or string literals. Very cool.

How would you access the return value object? Given obj is (int, bool), obj.Key and obj.Value? Or obj[0] and obj[1]?

Why would sugared destructuring not make sense in C#? Or first class events and delegates?

Destructuring just doesn't fit with the current language syntax. There are no copy constructors in C#, so something like [a, [b, c]] = [1, [2, 3]] makes no sense syntactically. In languages where declaring objects don't require a new, this syntax follows naturally.

For the simple case of say, destructuring a tuple, that could work well: a, b = ReturnsATuple(). But anything more general would just seem tacked onto the language.

But then again, tuples don't really fit well in C# either! Tuples are only useful if you don't have to declare their types, ever. Without full type inference, nothing is saved by using tuples over, say, an inline object.

I don't understand the significance of first class events, so I can't really comment on that. And as far as I know, delegates are first class now with the inclusion of lambdas.

Reply on news.ycombinator.com