i can’t explain how excited I am for this, so so so useful! No more [currentValue] ambiguities!!
Edit: would it be possible to have multiple expression/name pairs though instead of one?
3 Likes
Dear @Jason_Tamulonis. great achievement from you and the Codans that have been involved with the development and roll out 
Dear “after sales/education 
team” @maria, @BenLee, @Al_Chen_Coda some practical samples and a formula fitness on this 
newborn child would be welcomed by many Coda enthusiasts 
Lately I am quite busy with new challenges in my life, but hopefully the soonest I will be able to add some sample myself, I am sure other community members will be able to show off their take on WITHNAME()
7 Likes
I agree, one formula fitness for this new formula would be really cool 
4 Likes
@Jason_Tamulonis you still have some cases where it doesn’t work as expected. For example, we know that the result of AddRow() is a reference to the new row and we can insert it somewhere, e.g.
thisRow.ModifyRows(
[New row], SomeTable.AddRow(...)
)
But guess how this works (hint: it doesn’t create just one row):
2 Likes
Jack! Let’s do a hunker down and test some options.
2 Likes
Yeah I’m in 100%! It’ll be fun.
1 Like
Very nice
From a performance standpoint is there going to be a significant difference between using WithName vs adding a column to hold the intermediate formula result?
1 Like
It seems like WithName might help here, but it is hard to tell without more details. I’d suggested starting a thread with your use case over on Ask the community
1 Like
Putting an intermediate result in a column will basically guarantee that the value gets cached and recalculated less frequently. Using WithName may give you that benefit depending on how our optimizer handles your formula.
3 Likes
Awesome. Will do. Thank you!
1 Like
This. The same semantics already exist in other formulas, and it would allow us to define multiple variables without having to descend into nesting hell.
I understand that nested FormulaMaps were likely a major motivation for this feature (and those would be nested), but simplifying development would also be huge for formula-heavy applications.
I don’t want to trade column-hell for nesting-hell. Give us WithName with support for defining more than one variable!
5 Likes
Hi,
you pointed out a very important fact - the samples shown do generate several new rows and that is not what I am trying to achieve 
I am trying to create one (!) new row with several content from other rows which I am filtering and then scanning through with FormulaMap.
Did you find a solution for WithName creating one new row ?
Thanks!
This a very useful formula that I find myself using quite often. What would make it even better is if it could define multiple names in a similar fashion to SwitchIf or ModifyRows:
WithName(Value, Name, OptionalValue1, OptionalName1,…, Expression).
This would come in super handy as the top function in a very complicated calculation to make the code tidy and more readable.
Also, changing the function now to make multiple names work wouldn’t break backwards compatibility in existing docs - So I really hope Codans consider it.
PS: Excel does the same thing with the Let() function.
1 Like
Oops, just saw this was already mentioned here…So yeah, I second @Kenji_Prahyudi 's suggestion!
@nad you can stack:
WithName(1 + 1,two,
WithName(2 + 2,four,
RestOfYourFormula()
))
4 Likes
We thought about this when designing the formula. The trouble is that we don’t really have a pattern for varargs in the middle of a set of parameters (i.e. if there’s an unlimited set of optional parameters, they kind of have to be at the end). The alternative option was to reverse it and do something like WithName(expression, name1, value1, [name2], [value2]) but then auto-complete won’t work (you can’t use name1 in expression because you haven’t defined it yet). So we settled on this pattern. We often see people do what @Johg_Ananda mentioned – nest multiple WithName(..., WithName(...)) calls within each other.
4 Likes
Fair enough, and I guess it’s a common feature in programming language design to require putting optional arguments at the end of the parameter list.
I’ll have to settle for nesting WithName as per @Johg_Ananda tip, which still a an improvement over having multiple intermediate columns.
Maybe one day we can have some very light borrowing from imperative languages, a simple assignment operator " [var_name] := expression" that can be used anywhere in the formula coupled with “return [var_name OR Expression]” statement at the end of the formula would a godsend for power users.
1 Like
This is awesome. It saved the day when trying to figure out nested formulaMaps. Is there anyway to pin this to the beginning of this topic: Outer CurrentValue access so people don’t have to scroll through a ton of comments to eventually discover the solution?
@Anthony_Thong_Do wow man this is genius!! 
1 Like