The difference between defaults arguments with equals sign and brackets `arg a = 1` vs `arg a (1)`

Resources
14

Hm, I thought the general consensus on the github thread was that it’s dodgy or unreliable to count on nil overriding an argument default :wink: – and, several contributors quickly came up with cases where it might be valuable to pass nil (e.g., messaging latency), and the outcome was to change the behavior anyway. But here, nobody has a concrete use case for using nil as 0, so there should be even less objection to changing it.

BTW I’m not advocating one way or the other. One user asked a question about the behavior of sending arguments to synths, and I suggested a way that we could handle it differently. Though I disagree with the current behavior, my earlier message should be taken as somewhat short of a proposal.

FWIW the fact that SC replaces nil with 0 in outgoing OSC messages has caused data loss in the past:

	free { arg completionMessage;
		if(bufnum.isNil) {
			"Cannot call free on a Buffer that has been freed".warn;
			^nil
		} {
			server.listSendMsg(this.freeMsg(completionMessage))
		}
	}
  1. Read a bunch of buffers.
  2. Later, free one of them.
  3. And accidentally free it again. The buffer’s bufnum has been set to nil, so sclang would send [\b_free, nil], which changes to [\b_free, 0] during encoding, causing the wrong buffer to be freed.

^^ that is certainly bad (the reason why we put in a check for it is that this actually happened to somebody).

hjh

1 Like