bug(AztecMacro): Missing warning/error when structs used as return-values

[LHerskind]

The syntax improvements for doing function calls mean that you can now receive structs as the return values - nice 😎.

However, it gives us an issue when a contract was written without thinking about its return values potentially being consumed by some other contract.

For example, in the blacklist token, we have a UserFlags struct which contains a few roles and we have a get_roles that fetches the values for a given user.

It implements the serialize function as expected and frontends can easily decode it - hurray 🎉.

However, say it does not implement the deserialize function. If someone else tries to import my contract and call get_roles to get the UserFlags struct they can't!

This is because we are using the deserialize function here, which was not implemented.

To work around it I would need to go back to the old call syntax 😭

[Thunkar]

Do we have the actual error that is returned? I have to check, but for args I think it was pretty clear...maybe for return values the macro could output something more meaningful?

[LHerskind]

Do we have the actual error that is returned? I have to check, but for args I think it was pretty clear...maybe for return values the macro could output something more meaningful?

Currently no error when you write contract A, but you get it when you write contract B that calls A. And since A could be something already deployed or someone elses contract, seems kinda pain to have to change the interface manually to get it working.

[nventuro]

We could have the macro detect that if the function returns a type T then the traits should be implemented for it, couldn't we?

[Thunkar]

We could have the macro detect that if the function returns a type T then the traits should be implemented for it, couldn't we?

Yes, that's what I suggested in the scrum. However I wonder if we should halt compilation or just warn the user: "hey, this function won't be available in the interface". Same with args...