As we now have lenses with polymorphic update there is no reason to use the clumsy record update syntax anymore, right? So is there any chance that ghc might generate lenses instead of functions for record fields anytime soon? Or am I missing some drawbacks?

In this case the field1 and field2 lenses must be monomorphic since each alone cannot change the type of `Complicated a b. And in general there is no way to take the product of two lenses on the same source since in general they may not be disjoint.

The best solution I've been able to imagine is some sort of curly brace notation that takes a sequence of field names and produces a lens on the fly. That or we can simply punt on "complex polymorphic record updates" and say to anyone who needs this that they should hand-craft their own lens to do so.

I refer you to the earlier blog posts. Basically, roconnor explains how these lenses allow for polymorphic update, and edwardk explains how you can use this model to create "mirrored" lenses (read-only or write-only). Both posts explain how these lenses compose via the regular function composition operator, and the id function acts as the identity lens.

Other lens packages, as far as I am aware, do not provide polymorphic update, and either provide a painful API or do not provide one at all for "mirrored" lenses. Correct me if I'm wrong.

[edit] And of course, lens-family provides the classic operations on lenses; there's nothing lacking there that I am aware of. The major drawback right now is probably that the TH support is a bit primitive; not as full featured as, say, fclabels. I've gotten some initial feedback, and translated it into 3 feature requests. This one would be a great opportunity for the adventurous Haskeller to start learning some basic Template Haskell.

The major drawback right now is probably that the TH support is a bit primitive

The conceptual complexity is probably the far greater drawback. Unlike pretty much any other lens library out there, it's difficult to just know what lenses are, read the documentation, and understand what's going on here. By comparison, last of comprehensive TH support is a minor detail.

The main advantages from this approach is that you can compose normal lenses with lenses with polymorphic updates with more limited 'pseudo-lenses' for 'getters' and 'setters' that can only be used for their respective functions, using only (.) and id from the Prelude.

Moreover, to define a lens family you don't need to have any package dependencies at all.

Since the simplest type for a (polymorphic) lens can be defined using just Prelude types.

This means that library authors can create lenses into their types without incurring any dependency overhead whatsoever, unlike with other lens libraries.

So if you don't want to choose a lens library, just make polymorphic "lens families"

lens-family-core provides first class(†) functional references. In addition to the usual operations of getting, setting and composition, plus integration with the state monad, lens families provide some unique features:

Polymorphic updating

Cast projection functions to read-only lenses

Cast semantic editor combinators to modify-only lenses

(†) For optimal first-class support use the lens-family package with rank 2 / rank N polymorphism. Lens.Family.Clone allows for first-class support of lenses for those who require Haskell 98.