Solidity: Different notation for events

[axic]

Complementary to #2877.

Currently events feel like functions and even if internally they behave like that, they are not functions, but data structures. Therefore it may make sense making them similar syntactically to data structures.

event DepositReceived { uint value; address sender; }

function() payable {
  emit DepositReceived { value = 1, sender = msg.sender };
}

Not sure about the syntax yet. The following should be valid already:

event DepositReceived(uint value, address sender);
function() {
  DepositReceived({ value = 1, sender = msg.sender });
}

The difference is in the declaration and the emitting removes the parentheses to lessen the similarity to functions.

[MrTibbles]

Considering it is an object, should a colon not be used when defining the event parameters?
ie. emit DepositReceived { value: 1, sender: msg.sender };
Or is that too similar to JS (#3195)?

[axic]

You're right the current syntax for named arguments is with colons so the proposal is as follows:

event DepositReceived { uint value; address sender; }

function() payable {
  emit DepositReceived { value: 1, sender: msg.sender };
}

[federicobond]

I don't think it makes much of a difference to remove the parentheses when emitting. Structs are data structures too and they are created with parentheses.

With the introduction of the log or emit keyword in #2877 it should be much harder to confuse events with functions.

[chriseth]

I would also vote for not removing the parentheses if we require log or emit.

[axic]

So my current proposal is then:

event DepositReceived { uint value; address sender; }

function() payable {
  emit DepositReceived({ value: 1, sender: msg.sender });
}

This is consistent with the language, because the event definition is the same structure as a struct and the emit statement follows how named parameters are passed.

Apart from the definition change it should also disallow emitting events the old style, without naming the arguments.

[axic]

I would like to discuss this in 0.5.0 (potentially just allowing the the event definition to support both syntaxes), but restricting the emit part only in 0.6.0.

[chriseth]

My opinion is that a change in the syntax does not provide a real benefit and forces many changes in existing code.

[ekpyron]

I don't see much harm in allowing both event definition styles, even in the long term - that way everybody can decide for themselves whether they think of events as sets of data like structs or as functions :).
Fortunately, function calls with named arguments and struct initializations indeed have the same syntax, so no problem there.
Going that way this change could be done in any non-breaking release.

[axic]

Apart from the definition change it should also disallow emitting events the old style, without naming the arguments.

Actually I had this as a comment there but probably it is worth elevating it into its own discussion.