Solidity: Public function types not being recognized correctly

[ericssonaxel]

Version: 0.4.10
Platform: macOS

Possible solidity parser error when trying to define a public variable of function type.

Example:
https://gist.github.com/anonymous/54bac24c6173350b814c79dac5664625 compilation fails with the error message "ballot.sol:2:37: Error: Multiple visibility specifiers.
function(bytes memory) external public example;"

It seems reasonable that function(bytes memory) external public example; should be valid syntax for a public variable of the "function(bytes memory) external" type, so there might be a parser bug here.

[axic]

Good catch. Both external and public are visibility modifiers, so they cannot exists on that single line.

As a workaround you could use this:

contract C {
    function(bytes memory) external _example;

    function example() returns (function (bytes memory) external) {
        return _example;
    }

    function example(function (bytes memory) external new_example) {
        _example = new_example;
    }
}

Using a typedef feature (#1013 or #1100) or a better notation for function types (#1349) is the actual solution.

[ericssonaxel]

@axic Concerning workaround: adding the "getter" function manually is of course always an option, but the reason I wanted to set the variable to public was to automatically get a "getter" function for the function, just like you can do with other variables/maps.

I still think this is a bug since the external visibility modifier refers to the function and the public visibility modifier refers to the variable which happens to be of type function.

Barring supporting the function(bytes memory) external public example; syntax directly, it looks like (#1349) is the best way forward among options you proposed; it will probably make it easier to separate visibility modifiers for the function and the variable during parsing.

[chriseth]

Yes, it certainly is a bug in the parser.

[axic]

I would say it is rather a bug in the notation.

To fix it while keeping the notation:

• the parser would need to lift the useful restriction of single-modifier-only for function types,
• a new field must be added to the type to signal it is an accessor and
• the type checker needs to validate the a non-storage function type cannot be an accessor

[chriseth]

@axic I don't really follow. My suggested fix would be to only allow external and internal while parsing function types. Once the parser sees the public, it would divert back to parsing a variable - the public is not part of the type it is part of the variable declaration.

[axic]

Oh well, it is another bug too - we only allow internal and external for function types. In that case it should be simpler :)

[federicobond]

Just to clarify, these statements should be made valid and equivalent:

function(bytes memory) a;
function(bytes memory) internal a; // (explicit internal applies to the function type)
function(bytes memory) internal internal a;

function(bytes memory) external a;
function(bytes memory) external internal a;



md5-6e32790b032f8fbccdfcb3c6bfd4f7fe



function(bytes memory) internal external a;
function(bytes memory) internal public a;

Is that right?

[ericssonaxel]

Your first 5 examples should be correct by the following reasoning:

function(bytes memory) a;
internal variable called "a" containing 24 bytes that reference a public function

function(bytes memory) internal a;
internal variable called "a" containing 24 bytes that reference an internal function or internal variable called "a" containing 24 bytes that reference a public function

function(bytes memory) internal internal a;
internal variable called "a" containing 24 bytes that reference an internal function

function(bytes memory) external a;
internal variable called "a" containing 24 bytes that reference an external function or external variable called "a" containing 24 bytes that reference a public function

function(bytes memory) external internal a;
internal variable called "a" containing 24 bytes that reference an external function

The following should be incorrect since state variables can't be external:

function(bytes memory) internal external a;
external variable called "a" containing 24 bytes that reference an internal function.

The following should be correct (and the one the parser currently misses):
function(bytes memory) internal public a;
public variable called "a" containing 24 bytes that reference an internal function

Hope this helps

[axic]

@Balajiganapathi if you are looking for another task, this might be a good fit

[axic]

Assigned to @Balajiganapathi