TypeConstructor.sol

[vaniiiii]

Description

This pull request proposes the required functionality related to issue #5

It will allow developers who integrate the filecoin-solidity library into their codebase to construct common Filecoin types. Some of the types are not intended to be created by developers, such as FailCode, BatchReturn, etc. For other common types like BigInt and FilAddress, there are already methods that allow conversion to these types.

Proposed functions

    function dealLabelFromBytes(bytes calldata data) internal pure returns (CommonTypes.DealLabel memory) {}
    function dealLabelFromString(string calldata data) internal pure returns (CommonTypes.DealLabel memory) {}

Affected issues

• Closes #5

[maciejwitowski]

I think having constructors for common types is enough. I'd suggest to have cidFromString. Also, what about functions to create BigInt and UniversalReceiverParams (which also contain bytes and may be hard to figure out for devs).

[maciejwitowski]

@vaniiiii any update here?

[vaniiiii]

@vaniiiii any update here?

Hi @maciejwitowski,

• BigInt already has constructors/functions in ./utils/BigInts.sol that are able to convert from/to uint256/int256
• UniversalReceiverParams
  • We cannot understand why and when would a smart contract make the call to the universalReceiverHook (the only function that uses UniversalReceiverParams) as it is our understanding that this function on the filecoin actor wouldn't be called from the FEVM level and would only be called automatically when there is an asset transfer to that account.
  • Can you maybe point us where we could find more information about this method?
    • why it was exposed, its intended use, etc
• cidFromString
  • this one is difficult because the conversion is not straightforward
  • the current approach is to perform the CID string to bytes conversion off-chain through a separate library
    • For example: filecoin-project/community/discussions/633
  • having the conversion on-chain would require writing/introducing significant amount of functionality/testing code for different CID versions/multibase formats, and would cost a large amount of gas for the caller.
    • Here we need a decision whether to proceed with making this completely on-chain, and if so, guidance on what CID formats we need to support.

[maciejwitowski]

@vaniiiii I agree with all your points, thanks!