Does not expose view

[Yorkemartin]

would be nice to return both view and override - for the moment they still require manual addition afterward.

[frangio]

What information about override do you think should be exposed? Just that a function is an override?

[Yorkemartin]

if a function is marked as override - this implicitly changes the functionality of external functions.

i think override and view should be exposed - both are relevant to developers understanding external functions

[frangio]

I agree that view is relevant in API docs. But I don't understand why override would be included, since I see it as an implementation detail.

[Yorkemartin]

an example:

In Uniswap V3 - users may call a variety of external contracts which are tailored for different objectives. In one case, one will call the Router contract to execute a swap, but another may call a Quoter contract to simulate the execution of a swap and return some kind of data.

Both of these contracts, the router and the quote, use this same callback function, which is called by the core contract towards the end of the original function.

function uniswapV3SwapCallback( int256 amount0Delta, int256 amount1Delta, bytes memory path ) external view override {

It seems odd to hide this functionality - we are exposing an external function that is callable by the core contracts - but hiding that the function is marked override, which seems misleading and may confuse integrators by leading them to believe the two instances of uniswapV3SwapCallback are the same

[frangio]

Can you show the pieces of documentation that are affected by this? I remain of the opinion that override is just an implementation detail, and that if there is any possibility to mislead, it should be documented in prose.

[Yorkemartin]

im seeing your point now - i think just doing view is fine