Any update on this? <https://github.com/arrow-kt/a...

# arrow

[Quantum64]

Any update on this? https://github.com/arrow-kt/arrow/issues/2668
This is a pretty serious spec violation in my opinion. We don't want users to become dependent on this behavior.

[simon.vergauwen]

Hey @Quantum64,

The behavior has been like this for 5 years, so I am not sure what we should do.

There have been some discussions and ideas to replace Arrow Optics generator completely when FIR has been released.

so I suggest removing optional generation first.

This is also not an option, because then we also break any downstream usage 😕

[Quantum64]

My team decided to roll our own optics implementation to get around this and just for increased flexibility. It's not a huge effort. Perhaps the best solution is to document the current behavior and deprecate/replace this entire library down the line.

[simon.vergauwen]

Oh, interesting! Anything you can share?

Yes, that is exactly the idea. With the FIR plugin, which is now in a sort of preview, we can generate "synthetic" code and we can then generate actual code depending on usage.

That way we can avoid generating code that isn't used, but more interestingly we can inline the whole optic path. So we can completely optimize the Optics away to the most performant code.

[simon.vergauwen]

Documenting the current situation is probably/sadly the best option here. I have broken my head over this, but I don't see a way to do it without breaking it.

With FIR becoming available pretty soon, I feel it would be better to replace it completely in the next year.