# Unexpectedly long method signature in "Closest candidates" list

**URL:** <https://discourse.julialang.org/t/unexpectedly-long-method-signature-in-closest-candidates-list/32537>\
**Category:** General Usage\
**Tags:** question\
**Created:** [December 21, 2019, 4:48am UTC](https://discourse.julialang.org/t/unexpectedly-long-method-signature-in-closest-candidates-list/32537 "2019-12-21T04:48:36Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [December 21, 2019, 11:04am UTC](https://discourse.julialang.org/t/unexpectedly-long-method-signature-in-closest-candidates-list/32537/5 "2019-12-21T11:04:31Z")

</div>

> [@CameronBieganek](#):
>
> A method signature shouldn’t be 3629 characters long

Related:

> [@Why is the strange type signature of sqrt so long?](https://discourse.julialang.org/t/why-is-the-strange-type-signature-of-sqrt-so-long/32541/5):
>
> It is because of StridedArray being a union of a large number of complicated types.

The same also happens with stacktraces and the `methods` function, so it’s really just a display issue.

> <https://github.com/JuliaLang/julia/issues/33065>
>
> Stacktraces are in general pretty hard to read. Here's a list of gripes. I'm not… posting this as separate issues because I don't know what is bug and what is feature here. All tests are on 1.3alpha from an official release. This is related but not the same as https://github.com/JuliaLang/julia/issues/25375, which is about formatting.
> 
> Let's start small:
> 
> \`\`\`
> julia\> sqrt(-2)
> ERROR: DomainError with -2.0:
> sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
> Stacktrace:
> \[1\] throw\_complex\_domainerror(::Symbol, ::Float64) at ./math.jl:32
> \[2\] sqrt at ./math.jl:492 \[inlined\]
> \[3\] sqrt(::Int64) at ./math.jl:518
> \[4\] top-level scope at REPL\[4\]:1
> \`\`\`
> \* Where is \`./math.jl\`? 
> \* I don't care that \[2\] is inlined
> \* The last frame is unnecessary (the :1 definitely is, and I don't know what the \[4\] is)
> 
> Now a stdlib:
> \`\`\`
> julia\> lu(\[0 0;0 0\])
> ERROR: SingularException(1)
> Stacktrace:
> \[1\] checknonsingular at /buildworker/worker/package\_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/factorization.jl:19 \[inlined\]
> \[2\] #lu!#128(::Bool, ::typeof(lu!), ::Array{Float64,2}, ::Val{true}) at /buildworker/worker/package\_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:85
> \[3\] #lu! at ./none:0 \[inlined\]
> \[4\] #lu#134(::Bool, ::typeof(lu), ::Array{Int64,2}) at /buildworker/worker/package\_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:295
> \[5\] lu(::Array{Int64,2}) at /buildworker/worker/package\_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:286
> \[6\] top-level scope at REPL\[2\]:1
> \`\`\`
> \* The paths are bad; that means that nice things like ctrl-q will not work, and neither will the functionality in some editors that go to the path.
> \* The keyword arguments lowering, which should really be an implementation detail, is exposed here, and confusing (wtf is \[3\]?)
> 
> \`include\`d user files:
> \`\`\`
> julia\> include("scratch.jl")
> ERROR: LoadError: UndefVarError: qsd not defined
> Stacktrace:
> \[1\] f() at /home/antoine/scratch.jl:2
> \[2\] top-level scope at /home/antoine/scratch.jl:4
> \[3\] include at ./boot.jl:328 \[inlined\]
> \[4\] include\_relative(::Module, ::String) at ./loading.jl:1094
> \[5\] include(::Module, ::String) at ./Base.jl:31
> \[6\] include(::String) at ./client.jl:432
> \[7\] top-level scope at REPL\[3\]:1
> in expression starting at /home/antoine/scratch.jl:4
> \`\`\`
> \* Five frames for the include are hard to read
> \* Having the information at the bottom is confusing: where am I supposed to find the source of the error? In the stacktrace or at the bottom?
> \* The LoadError: UndefVarError is annoying (it gets worse for more complex cases, ie multiple includes)
> 
> Failing tests:
> \`\`\`
> ERROR: LoadError: LoadError: LoadError: DomainError with -2.0:
> sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
> Stacktrace:
> \[1\] throw\_complex\_domainerror(::Symbol, ::Float64) at ./math.jl:32
> \[2\] sqrt at ./math.jl:492 \[inlined\]
> \[3\] sqrt(::Int64) at ./math.jl:518
> \[4\] @SArray(::LineNumberNode, ::Module, ::Any) at /home/antoine/.julia/packages/StaticArrays/3KEjZ/src/SArray.jl:83
> \[5\] include at ./boot.jl:328 \[inlined\]
> \[6\] include\_relative(::Module, ::String) at ./loading.jl:1094
> \[7\] include(::Module, ::String) at ./Base.jl:31
> \[8\] include(::String) at ./client.jl:432
> \[9\] top-level scope at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/runtests.jl:19
> \[10\] include at ./boot.jl:328 \[inlined\]
> \[11\] include\_relative(::Module, ::String) at ./loading.jl:1094
> \[12\] include(::Module, ::String) at ./Base.jl:31
> \[13\] include(::String) at ./client.jl:432
> \[14\] top-level scope at none:5
> in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/SArray.jl:30
> in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/SArray.jl:1
> in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/runtests.jl:19
> ERROR: Package StaticArrays errored during testing
> \`\`\`
> I'm a bit confused about what's going on here to be honest... 
> 
> 
> I did not try with the other ways of including code, macros, etc. So, to sum up, in subjective increasing order of seriousness
> \* There are minor printing things that could be nicer: REPL frames, LoadError nesting, inline, \`./\` path for base
> \* The keyword argument lowering is a bit nasty
> \* The paths on official releases should be corrected
> \* The stacktraces with \`include\` are very hard to parse. This is possibly the most controversial issue because enhancing this would mean "lying" to the user, ie treating \`include\` as a special function

---

_[View the full topic](https://discourse.julialang.org/t/unexpectedly-long-method-signature-in-closest-candidates-list/32537)._