Get rid of SingleVariable

[blegat]

Having a separation between the index type VariableIndex and the function type SingleVariable is nice in principle but it's not the best for usability and causes confusions like #1380.
As VariableIndex has no supertype, it could simply be AbstractScalarFunction and we won't need SingleVariable.
The deprecation path doesn't seem too bad, we can do

const SingleVariable = VariableIndex
function VariableIndex(vi::VariableIndex)
    @warn "SingleVariable is deprecated"
    return vi
end

I always end up having to convert between VariableIndex and SingleVariable and it's a difference of behavior with JuMP that makes it difficult to write a code that works both for JuMP and MOI model as JuMP has VariableRef that works both as the reference and the function while in MOI we have two different things.

[odow]

I understand the motivation. But this seems like we're breaking an abstraction. Is VariableIndex <: AbstractScalarFunction?

#1380 is user-error. MOI isn't meant to be user-friendly. Wrapping a VariableIndex in SingleVariable is effectively a no-op.

I think this has too many far-reaching consequences than I'm happy with to release in MOI 0.10. Can it be a MOI 2.0 thing?

[blegat]

Is VariableIndex <: AbstractScalarFunction?

Yes, just like JuMP.VariableRef <: JuMP.AbstractJuMPScalar.

MOI isn't meant to be user-friendly

We don't want to sacrifice anything for the sake of user-friendliness, I agree. But what are we sacrificing here ? I'm failing to see any advantage brought by SingleVariable.
The advantage of using VariableIndex instead of Int64 directly is that it catches bug when the user was giving a constraint index instead of a variable index. I think this is a good thing.
However, in which case would the distinction between SingleVariable and VariableIndex catch any bug ?

Can it be a MOI 2.0 thing?

I'm hoping MOI 2.0 is far from now so it might be worth doing this now.
Even is usability of MOI is less critical than the usability of JuMP, we still encourage developers to extend JuMP by creating MOI layers so it's still important.
Over the few years of using MOI, I've lost quite some time and had to complicate code because of SingleVariable and I would assume it's the case for many others as well. It's actually quite bad once you want to follow the workflow:

@variable(model, x[1:3])
@constraint(model, x[1] + 2x[2] + 3x[3] <= 4)

that you want to equivalently write

x = MOI.add_variables(model, 3)
MOI.add_constraint(model, MA.@rewrite(x[1] + 2.0x[2] + 3.0x[3]), MOI.LessThan(4.0))

It would be nice if it was the case but MOI.Utilities.operate only works on AbstractFunction so this does not work as VariableIndex is not an AbstractFunction.
So what I currently do is

fx = MOI.SingleVariable.(x)
MOI.add_constraint(model, MA.@rewrite(fx[1] + 2.0fx[2] + 3.0fx[3]), MOI.LessThan(4.0))

which is annoying.
Then when you want to pass x to a function, what do you give ? x or fx ? If the function gets or sets attributes you should give x, if it creates functions, you should give fx. What if it does both ? Do you pass x and fx ? Or pass one of the two and compute the other one in the function ?
I end up doing this every single time I use MOI. I have the feeling we don't get more complain about this (except for instance #1380) because users tend to create functions using ScalarAffineFunction constructor instead of MutableArithmetics or Utilities.operate but that might change now that these features are better documented.

[odow]

@mlubin needs to have a look at this one.

[blegat]

Note that we have this since before the first release of MOI

MathOptInterface.jl/src/constraints.jl

Lines 233 to 239 in 971e430

	function add_constraint(
	model::ModelLike,
	v::VariableIndex,
	set::AbstractScalarSet,
	)
	return add_constraint(model, SingleVariable(v), set)
	end

[mlubin]

If we define VariableIndex <: AbstractScalarFunction then on a first glance this seems okay. I don't see when there might be ambiguities between the interpretation of the object as an index or as a function. It's worth at least following up on @blegat's draft PR to see what the overall impact will be.