Remove RequireQualifiedAccess from Optic module

[cmeeren]

I'd like to open Optic so I can just do x |> set foo_ "bar" instead of x |> Optic.set foo_ "bar", but Optic is marked with RequireQualifiedAccessAttribute.

This may be relevant for other modules as well; haven't checked.

[varon]

Typically you'd use the operators for this instead.

[cmeeren]

Can you do x |> set a_ "a" |> set b_ "b" |> ... with operators?

In any case, I often prefer functions over custom operators for legibility reasons, and it's nice to have the option. 😊 Particularly since The change is trivial.

[et1975]

As long as we are throwing personal preferences in, I'm the opposite - I prefer explicit module names, especially when the chance of name collision is high and Lens and Prism would typically be used in the same context.
For personal preferences auto-opened Prelude in your project file is the way to go. That would be ideal place to alias functions you want into an auto-opened module.

[cmeeren]

Sure, but removing RequireQualifiedAccessAttribute doesn't change anything for you or other users who prefer explicit module names. It's a tiny and fully backwards compatible change that doesn't impact anyone except those that choose to make use of it. It makes Aether more flexible without adding any maintenance burden or impacting those who aren't interested.

[varon]

@cmeeren - the entire way Aether is written, even down to the type level is designed to be maximally flexible and compatible.

In general, qualified access serves as a stopgap measure in the absence of proper HKT support, much like List, Set and Map do.

The library (in general) tries to provide some conventions on how to do things; with the operators offering very decent syntax for most tasks. if you'd like to write your own get/set functions, they're incredibly trivial to do in your own prelude.

[cmeeren]

stopgap measure

Against what, would be my question. I don't see the harm in allowing the module to be opened. It won't impact anyone except those users who deliberately try to do it.

much like List, Set and Map do.

I don't think it's a fair comparison; those modules (and Option, Array, etc.) contain a lot of functions, many of which have the same names (since they're all functors/monads/etc.). Optic contains get, map, and set (and hopefully over at some point, #57).

and Lens and Prism would typically be used in the same context.

This issue is only about Optic, not Lens and Prism.

---

In any case, though I stand by my position that this would be a convenience, it's a fairly minor one (as you point out), and not something I personally feel is worth further discussion. Feel free to close. 🙂