3 ms·

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

by mseepgood 14y ago

masklinn 14y ago
There is no difference, a call can trivially be deferred by wrapping it in a function.
- mseepgood 14y ago
  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.
  - masklinn 14y ago
    > 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.
    - jkn 14y ago
      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.
  - 0xABADC0DA 14y ago
    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.
jgeralnik 14y ago
Just to give an example from I project I'm working on now: output.WriteString("<statements>\n") defer output.WriteString("</statements>\n")

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

masklinn 14y ago

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

mseepgood 14y ago
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.
- masklinn 14y ago
  > 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.
  - jkn 14y ago
    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.
- 0xABADC0DA 14y ago
  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.

jgeralnik 14y ago

Just to give an example from I project I'm working on now: output.WriteString("<statements>\n") defer output.WriteString("</statements>\n")