Hacker News Reader

Comment by mseepgood | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com