Oscar Dowson

Bikeshed * `@_nl` ? * `@nl_esc` * `@scary_nl` * `@nl_boo` (@matbesancon) * `@nlexpr(...)` * `@nl_expr(...)` * `@raw_nl_expr(...)` * `@raw_nonlinear_expr(...)` * `@raw_nl` * `@nl_rewrite` * `@force_nl` * `@force_nl_expr` * `@force_nonlinear` *...

This could use a review. I've updated to `@force_nonlinear` as discussed.

Adding an epigraph variable also fails: ```Julia julia> using JuMP julia> import Nonconvex julia> Nonconvex.@load Ipopt [ Info: Attempting to load the package NonconvexIpopt. [ Info: Loading succesful. julia> model...

What is preventing Hypatia or a bridge from supporting `VectorAffineFunction{ComplexF64}-in-NormOneCone` at the moment? Why do we need to define complex cones? Perhaps this issue is an ask for a bridge?

@blegat should chime in here. He has more thoughts on the design of the Complex bridges.

I don't really understand the problem of supporting `VectorAffineFunction{ComplexF64}-in-NormOneCone`. We do it for `ScalarAffineFunction{ComplexF64}-in-EqualTo{ComplexF64}`. If some bridges are invalid, then that is a bug and they should be fixed to...

See https://github.com/jump-dev/MathOptInterface.jl/pull/2451

> and it gets bridge by the SlackBridge which My point is that it should **NOT** get bridged by slack bridge, because slack cannot apply to complex functions. That is...

See https://github.com/jump-dev/MathOptInterface.jl/pull/2468 for the bug fix removing Complex support from some bridges

So I didn't want to break existing code (like Polynomials) for which we don't know. So we had to default to false positives. So we'd need to define `is_maybe_complex(::Any) =...