Unsupported attributes

[blegat]

I think #1613 should be reverted. The fallback of set is already throwing the expected error. Why was that PR needed?

[odow]

Because generic fallbacks get in the way. I'll find an example after the call today.

[odow]

Talked to @blegat offline. We can close this.

[blegat]

I understood #1608 from our talk offline but I still don't understand #1613.
Is it to make

MathOptInterface.jl/src/Test/test_model.jl

Lines 618 to 621 in 2d76d9c

	@test_throws(
	MOI.UnsupportedAttribute,
	MOI.copy_to(model, BadModelAttributeModel()),
	)

work in the case where you have bridge-cache-optimizer layers ? Without this, I assume it just get set to the cache without error.

[odow]

#1613 is because some solvers, e.g., GLPK, call MOI.Utilities.pass_attributes in their copy_to implementations. It would be redundant for them to have to do a double loop to check for supports.

There's an issue I have been putting off until I work on JuMP: should a caching optimizer accept attributes and constraints that the optimizer doesn't support if the caching optimizer is in EMPTY_OPTIMIZER. We're a bit half-half on this front.

Edit: here's the issue: jump-dev/JuMP.jl#2654

[blegat]

So this is a workaround because MOI.set(::GLPK.Optimizer, ::UnsupportedAttribute, value) does not throw the right error due to some dispatch issue with the fallback ? Why not fix MOI.set(::GLPK.Optimizer, ::UnsupportedAttribute, value) like it was done for the AbstractBridgeOptimizer?

[odow]

There are multiple ways we could have done it. What's so wrong about checking supports here?

[blegat]

If MOI.set(::GLPK.Optimizer, ::UnsupportedAttribute, value) is incorrect and it's passing the tests, then #1613 is hiding the bug.
Assuming MOI.set is correctly implemented, there is no need for this support. We don't want to cover bugs.

[odow]

Fair point. I don't remember the detail, so I'll take another look.