Coda has a rich formula language composed of many different formulas, data types, and objects. A big part of making a good formula user experience is making sure that Coda can understand the data types of every part of your formula, so that we can provide relevant autocomplete, check for errors, and much more.

In some simple formulas the like Date() the typing is very specific. It takes a number for the year, month, and day and returns a date. In other formulas the typing is much more dynamic. Take Max() for example it takes a list of numeric values that could be formatted numbers, currency, percent, dates, or duration, and based on the input data type we determine what the output data type would be.

This gets a bit more complicated when you introduce more complicated data types like Rows, pack Objects, and Controls. As some of our users have noticed we would sometimes lose the full understanding of a data type when it passed through a formula. A common example of this was doing [Table].First().[Column]. Attempting to project the column would lead to a very confusing error about expecting a row, but the data type being a row, which we apologize for. The reason for this was the type system knew the data type was a row, but didn’t know which table it belonged to.

We recently did an overhaul of how we pass around type understanding in formula engine to address a whole category of these issues. As a result Coda formulas should no longer lose type information when passing through a formula. This made it possible to now do projections off of many common list functions like First, Last, Nth, List, ListCombine, and others.

As an added bonus we improved the type understanding on Controls, so that you should no longer need to use the Value accessor to project off of the references in the Control. The Value accessor will still continue to work, but hopefully in the future we can migrated everyone off it.