The optics in the new ZIO Schema I am working on are "reflective optics" (a term I just made up, but it fits). This means that, in addition to letting you do get- & set-like things (like legacy optics), you can ALSO access the reified structure of the underlying types. This lets you use the optics in DSLs, like SQL, DynamoDB, or Cassandra. e.g.: selectFrom("foo").where(Person.age > 20) Interestingly, however, reflective optics beat legacy optics at their own game in one important way: killer error messages. Optic composition invariably introduces optionality in "getting". With almost all legacy optics, you learn that SOME value had an unexpected constructor, but you don't get any information on the error, leaving you to puzzle over why some update operation didn't work. With reflective optics, it should be possible to support brilliant error messages, along the lines of: "In Order.items[*].billingAddress.country, expected field billingAddress to be Some but found None." Boom! You know exactly how your expectation differed from reality when doing some targeted operation on a deeply nested structure. As a bonus, reflective optics are also eminently usable as "keys" in maps, because the data they contain is sufficient for disambiguation. This means another place where they will shine is in applications involving data-generic metadata. Currently, if you have a deeply nested structure like Order, there's no good type-safe, expression-oriented way to attach metadata to particular parts of its substructure--not without modifying it and adding slots for the metadata. For example, you might want to attach documentation, validation rules, or format hints. With reflective optics, you can now attach arbitrary metadata to arbitrary parts of a substructure. For example: val validatedCodec = orderCodec.validate((items)(billingAddress)(country))(CountryCodes.contains(_)) This is going to open up new applications for optics, as well as greatly simplify some tasks that were possible before, but only at great cost to ergonomics (using fixed point data and recursion schemes, zippers, etc.). In short, reflective optics aren't your grandpa's optics--they're way better! 😅

My recent experiment is a success! The next version of ZIO Schema will be rad: - generic construction / deconstruction WITHOUT tuple boxing or primitive boxing (!!!) - real optics that can ALSO be used in DSLs - helps you derive type class instances without macros 😱