Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse errors on anonymous function return type annotations #23072

Open
dalum opened this issue Aug 1, 2017 · 7 comments
Open

Parse errors on anonymous function return type annotations #23072

dalum opened this issue Aug 1, 2017 · 7 comments
Labels
domain:error messages Better, more actionable error messages

Comments

@dalum
Copy link
Contributor

dalum commented Aug 1, 2017

julia> function (x, y)::Complex
    x + y
end
ERROR: syntax: expected "(" in function definition

julia> (x, y)::Complex -> x + y
ERROR: syntax: "(x, y)" is not a valid function argument name

Also related (as noted by @pfitzseb):

julia> f = (x)::Float64 -> x
(::#1) (generic function with 1 method)

julia> f(2)
ERROR: MethodError: no method matching (::##1#2)(::Int64)
@JeffBezanson
Copy link
Sponsor Member

function (x,y)::T can work, but will require a comma for one argument ((x,)::T). The -> case I believe is impossible: since parentheses are not required around the arguments, it's ambiguous whether (x)::T is a function returning T or accepting T. This will be especially true when we implement #6614, since (x,y) itself will be a valid single formal argument.

@JeffBezanson
Copy link
Sponsor Member

JeffBezanson commented Aug 1, 2017

Also, since the function body in a -> b is a single expression, I think it makes more sense to do the conversion on the right side, a -> convert(T, b). The special return type syntax is mostly useful because in a long-form function there is no expression to apply convert to. This is only missing some nicer syntax, like a -> b as T.

Also note that function f(x)::T makes sense because T will actually be the type of f(x). In function (x,y)::T, T is not the type of (x,y).

@dalum
Copy link
Contributor Author

dalum commented Aug 1, 2017

But what about (a,)::T -> b? Couldn't that still work? If that is problematic, I don't mind if this functionality is only available for anonymous functions defined using the long-form function (x, y) ... end syntax.

singularitti added a commit to MineralsCloud/EquationsOfState.jl that referenced this issue Nov 4, 2018
We cannot write anonymous functions with return type,
because it will cause parsing ambiguity. See
JuliaLang/julia#23072.
@ChrisRackauckas
Copy link
Member

This impacts opaque closures since then you don't have a way to specify the return type.

f2 = Base.Experimental.@opaque function (x::Float64, y::Float64)
    2x + y
end

works, but

f2 = Base.Experimental.@opaque function (x::Float64, y::Float64)::Float64
    2x + y
end

hits this error.

@Moelf
Copy link
Sponsor Contributor

Moelf commented Sep 28, 2022

function (x,y)::T can work, but will require a comma for one argument ((x,)::T)

actually,

julia> function (x, y)::Float32
         return x
       end
ERROR: syntax: ambiguous signature in function definition. Try adding a comma if this is a 1-argument anonymous function.
Stacktrace:
 [1] top-level scope
   @ none:1

julia> function (x, )::Float32
         return x
       end
ERROR: syntax: ambiguous signature in function definition. Try adding a comma if this is a 1-argument anonymous function.

I'm not sure what's going on here

@pfitzseb
Copy link
Member

Pretty sure Jeff meant that as "can be made to work". The current parser doesn't handle either case.

@Moelf
Copy link
Sponsor Contributor

Moelf commented Sep 28, 2022

ah

Try adding a comma if this is a 1-argument anonymous function.

confused my

@brenhinkeller brenhinkeller added the domain:error messages Better, more actionable error messages label Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:error messages Better, more actionable error messages
Projects
None yet
Development

No branches or pull requests

6 participants