Amount and shares as input

[MathisGD]

No description provided.

[MerlinEgalite]

I'm not a real fan of this solution as it complexifies integrator's understanding

[Rubilmax]

Come on, a simple NATSPEC and everyone understands that you either need to provide amount or shares ; I understand there are people that don't understand Solidity well but they still succeeded in integrating Aave and Compound, while these 2 protocols are not simple nor do they have simple interfaces (How are cTokens and aTokens simple? remember interestRateMode and referralCode?)

Even with this change, Blue is still the simplest protocol to integrate

[MerlinEgalite]

Come on, a simple NATSPEC and everyone understands that you either need to provide amount or shares ; I understand there are people that don't understand Solidity well but they still succeeded in integrating Aave and Compound, while these 2 protocols are not simple nor do they have simple interfaces (How are cTokens and aTokens simple? remember interestRateMode and referralCode?)

Even with this change, Blue is still the simplest protocol to integrate

Ok but which one I choose? Why? In which configuration should I use amount instead of shares? Those are questions that you now need to ask yourself when integrating Blue while you did not before. This is not easing integration for sure.

[Rubilmax]

We could have the following NATSPECs:

/// @notice Supplies the given amount of assets or shares to the given market on behalf of `onBehalf`,
///         optionally calling back the caller's `onBlueSupply` function with the given bytes of data.
/// @dev Either `amount` or `shares` should be zero.
///      Most usecases should rely on `amount` as an input so the caller
///      is guaranteed to have `amount` tokens pulled from their balance,
///      but the possibility to mint a specific amount of shares is given
///      for full compatibility and precision.

[Jean-Grimal]

Also thought about this solution yesterday, but actually it looks very weird tbh

[pakim249CAL]

IMO only the amount/share check looks weird, which is resolved well by @makcandrov 's solution.

[MerlinEgalite]

We could have the following NATSPECs:

/// @notice Supplies the given amount of assets or shares to the given market on behalf of `onBehalf`,
///         optionally calling back the caller's `onBlueSupply` function with the given bytes of data.
/// @dev Either `amount` or `shares` should be zero.
///      Most usecases should rely on `amount` as an input so the caller
///      is guaranteed to have `amount` tokens pulled from their balance,
///      but the possibility to mint a specific amount of shares is given
///      for full compatibility and precision.

I'm still not convinced by this. The integrator still needs to reflect more. What's the upside of this solution?

[Rubilmax]

What's the upside of this solution?

We are sure it fits any usecase

[julien-devatom]

The most permissive interface. Finally, I find interdependency between arguments not so bad. This is easy to do or verify.
For integrators, you can still provide a library with 2 different interfaces, supplyShares & supplyAmount, but the primitive permits both.

[Jean-Grimal]

Another solution could be to replace the input uint256 shares by bool max, and just do a check on this bool to know if the user wants to withdraw/repay max or not
In the end it is very close to #246 with an additional argument, but without the type(uint256).max @MathisGD hates so much.