{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/vyper/issues/1170","repository_url":"https://api.github.com/repos/ethereum/vyper","labels_url":"https://api.github.com/repos/ethereum/vyper/issues/1170/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/vyper/issues/1170/comments","events_url":"https://api.github.com/repos/ethereum/vyper/issues/1170/events","html_url":"https://github.com/ethereum/vyper/issues/1170","id":395727282,"node_id":"MDU6SXNzdWUzOTU3MjcyODI=","number":1170,"title":"VIP Structs in Events","user":{"login":"fubuloubu","id":3859395,"node_id":"MDQ6VXNlcjM4NTkzOTU=","avatar_url":"https://avatars3.githubusercontent.com/u/3859395?v=4","gravatar_id":"","url":"https://api.github.com/users/fubuloubu","html_url":"https://github.com/fubuloubu","followers_url":"https://api.github.com/users/fubuloubu/followers","following_url":"https://api.github.com/users/fubuloubu/following{/other_user}","gists_url":"https://api.github.com/users/fubuloubu/gists{/gist_id}","starred_url":"https://api.github.com/users/fubuloubu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fubuloubu/subscriptions","organizations_url":"https://api.github.com/users/fubuloubu/orgs","repos_url":"https://api.github.com/users/fubuloubu/repos","events_url":"https://api.github.com/users/fubuloubu/events{/privacy}","received_events_url":"https://api.github.com/users/fubuloubu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2019-01-03T21:16:43Z","updated_at":"2019-01-04T20:08:03Z","closed_at":null,"author_association":"MEMBER","body":"## Simple Summary\r\nAllow emitting structs in events\r\n\r\n## Abstract\r\nABIv2 will allow emitting structs inside events.\r\nThis behavior is not well-defined (@davesque please confirm).\r\n\r\n## Motivation\r\nWorking with structs as input arguments, it may be useful to emit structs inside events for the client-side to use after a transaction has been mined e.g. a Deposit transaction in Plasma.\r\n\r\nAs mentioned by @charles-cooper in #1019 \r\n\r\n## Specification\r\nSpecification is WIP, but here are a few possibilities:\r\n\r\nDirectly outputing a struct:\r\n```python\r\nstruct Transaction:\r\n    prevBlkNum: uint256\r\n    tokenId: uint256\r\n    newOwner: address\r\n    signature: bytes[65]  # VRS\r\n\r\nDepositAdded: event({txn: Transaction})\r\n\r\ndef foo(txn: Transaction):\r\n    log.DepositAdded(txn)\r\n```\r\n\r\nOutputting only certain members of a struct:\r\n```python\r\n# Should we allow indexing event args in this way?\r\nDepositAdded: event({tokenId: uint256, newOwner: address})\r\n\r\ndef foo(txn: Transaction):\r\n    # Compiles to `log.DepositAdded(txn.tokenId, txn.newOwner)`\r\n    log.DepositAdded(**txn)  # because who doesn't love kwargs?\r\n```\r\n\r\nIndexing:\r\n```python\r\n# Do we allow structs to be indexed? ABIv2 is inconclusive I believe\r\nDepositAdded: event({txn: indexed(Transaction)})\r\n\r\n# Should we allow indexing event args in this way?\r\nDepositAdded: event({tokenId: indexed(uint256), newOwner: address})\r\n\r\n# Should we allow indexing members indirectly?\r\nDepositAdded: event({txn: Transaction}, indexed=[txn.newOwner, txn.tokenId])\r\n```\r\n\r\n\r\n## Backwards Compatibility\r\nNo backwards compatibility issues\r\n\r\n## Copyright\r\nCopyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)\r\n"},"comment":{"url":"https://api.github.com/repos/ethereum/vyper/issues/comments/451554527","html_url":"https://github.com/ethereum/vyper/issues/1170#issuecomment-451554527","issue_url":"https://api.github.com/repos/ethereum/vyper/issues/1170","id":451554527,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTU1NDUyNw==","user":{"login":"charles-cooper","id":3867501,"node_id":"MDQ6VXNlcjM4Njc1MDE=","avatar_url":"https://avatars2.githubusercontent.com/u/3867501?v=4","gravatar_id":"","url":"https://api.github.com/users/charles-cooper","html_url":"https://github.com/charles-cooper","followers_url":"https://api.github.com/users/charles-cooper/followers","following_url":"https://api.github.com/users/charles-cooper/following{/other_user}","gists_url":"https://api.github.com/users/charles-cooper/gists{/gist_id}","starred_url":"https://api.github.com/users/charles-cooper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/charles-cooper/subscriptions","organizations_url":"https://api.github.com/users/charles-cooper/orgs","repos_url":"https://api.github.com/users/charles-cooper/repos","events_url":"https://api.github.com/users/charles-cooper/events{/privacy}","received_events_url":"https://api.github.com/users/charles-cooper/received_events","type":"User","site_admin":false},"created_at":"2019-01-04T20:08:03Z","updated_at":"2019-01-04T20:08:03Z","author_association":"CONTRIBUTOR","body":"@fubuloubu I like the syntax for directly outputting a struct but I think the member selection is too magical. Users should have to specify which fields they want to log/index.\r\n\r\nRe. indexing on a struct, according the EVM spec, each LOG topic is one word, so we would have to apply a map from struct to uint256/bytes32 (e.g. keccak256) and I think that is overfunctioning on behalf of the user. Besides, the topic data is not accessible so I'm having trouble thinking of a case where somebody would want to index a topic but not already have the hash.\r\n\r\nI think Solidity uses the ABIv2 encoding but I'm not sure if it is packed or unpacked. For compatibility we should use whatever it uses."}}
{"actor":{"display_login":"charles-cooper"}}