Hacker News Reader

Comment by masklinn | Hacker News Reader

> which is how you'd refer to functions in Python or Javascript rather than their return value

It's what you'd do in pretty much every language other than Go, really. And it's quite annoying when defining the function inline: you have to remember the extraneous parens to call the function in-place.

> Python tuples are probably a more general (and better?)

Python's tuples are indeed more general, "better" is a more complex issue as the language does not provide much support for tuples management.

Erlang's tuple support is significantly better than Go's MRV-specific syntax in my opinion, so is Haskell's (although in Haskell you often would use dedicated data types where Go would use tuples, as you can pattern-match — and unpack — pretty much anything and declaring a datatype is extremely easy)

View on HN

It's not a function reference. It's a deferred call: the call can have arguments.

There is no difference, a call can trivially be deferred by wrapping it in a function.

But then you would have to wrap one-liners more often. The syntax of the 'defer' keyword is obviously designed to match the syntax of the 'go' keyword for launching Goroutines, and it would be annoying to wrap every 'go' call with arguments in an anonymous function without arguments.

> But then you would have to wrap one-liners more often.

Would you really? Most of the examples I see over and over take no argument, the common case most definitely seem to be that. Not to mention it is not hard to design a HoF wrapping a callable and arguments, and deferring the application of one to the others.

> The syntax of the 'defer' keyword is obviously designed to match the syntax of the 'go' keyword for launching Goroutines

Which I consider problematic for the same issue.

> it would be annoying to wrap every 'go' call with arguments in an anonymous function without arguments.

No more annoying that calling functions being deferred, or coping with the weird irregularity of evaluating all sub-expressions but not the top-level one.

Sorry but I think your idea would just make the language less consistent. A call is a call, it can be deferred or made asynchronous (with the go keyword). In the latter case at least it is very common to specify arguments. Having a syntax to defer a function call, that only works with functions that take no argument, would be weird and inconsistent.

Which is why "defer" and the "go" should operate on blocks or statements, not expressions. For instance:

    defer { result++; }

Instead of:

    defer func() {
        result++;
    }();

Also that you need such an ugly syntax just to not silently ignore return values from "defer" and "go" speaks volumes. For instance the "defer f.Close()" in the original post ignores errors from close, and with no exceptions these are just lost. It should be something more like:

    defer func() {
        err := f.Close();
        // handle error
    }();

You are basically always going to use this form anyway if you care about error handling. But lack of error handling in Google Go is another issue entirely.

Just to give an example from I project I'm working on now:

  output.WriteString("<statements>\n")
  defer output.WriteString("</statements>\n")

Reply on news.ycombinator.com