Fix evalpoly for no coefficients case

[Sagar-Ramchandani]

This resolves #56699

I went with the route of returning zero(x) for evalpoly(x,p) instead of an error.
This is because according to me a naive implementation of evalpoly would use a counter initialized to zero and loop over the coefficients and would thereby return zero in case of no coefficients.

Please let me know if I have made a mistake in this pull request as this is my first PR.

[nsajko]

Don't unnecessarily increase diff size. Leave this line as it is.

[Sagar-Ramchandani]

Sorry for that. I have fixed it in the latest commit.

[nsajko]

I'd suggest restricting this PR to fixing just the Tuple case. No sense in making things unnecessarily difficult.

[nsajko]

Regarding the Tuple case, I'd suggest fixing the faulty method signatures as the starting point:

diff --git a/base/math.jl b/base/math.jl
index 16a8a54..c6acfca 100644
--- a/base/math.jl
+++ b/base/math.jl
@@ -91,7 +91,7 @@ julia> evalpoly(2, (1, 2, 3))
 17
 ```
 """
-function evalpoly(x, p::Tuple)
+function evalpoly(x, p::Tuple{Any, Vararg})
     if @generated
         N = length(p.parameters::Core.SimpleVector)
         ex = :(p[end])
@@ -116,7 +116,7 @@ function _evalpoly(x, p)
     ex
 end
 
-function evalpoly(z::Complex, p::Tuple)
+function evalpoly(z::Complex, p::Tuple{Any, Any, Vararg})
     if @generated
         N = length(p.parameters)
         a = :(p[end])

After that, adding a single method for empty tuples should suffice to give a friendly error message, without causing any ambiguity.

[martinholters]

Suggested change

	N == 0 && return zero(z)
	N == 0 && return zero(z) * zero(eltype(p))

for improved type-stability? Although that will throw if zero(eltype(p)) is undefined, e.g. if p == Any[], so not sure this is better.

[Sagar-Ramchandani]

Thank you for your suggestion, but I personally think this change should not be made due to the possible undefined error in zero(eltype(p)) as you pointed out.

[Sagar-Ramchandani]

I'd suggest restricting this PR to fixing just the Tuple case. No sense in making things unnecessarily difficult.

I am not sure I understand you correctly. Are you suggesting that I remove the changes made to the 'Vector' cases?

Regarding the Tuple case, I'd suggest fixing the faulty method signatures as the starting point:

I have fixed the faulty method signatures in the latest commit.

[Sagar-Ramchandani]

I will be closing this PR because of a more general PR #56707