Comment by hackinthebochs | Hacker News Reader

Comment by hackinthebochs | Hacker News Reader

Parent Full thread

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]?

Reply on news.ycombinator.com