You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Defining new keys works as expected if you don't use merge functions in the RHS:
merge{}{new=[];nested.new=[];}
{
"nested": {
"new": []
},
"new": []
}
But if you use a merge function it fails:
merge{}{new=append[];}
error: evaluation aborted with the following error message: '
a fresh right-hand-side cannot be an array merge function
at 'new':
- rhs: lambda @ …
Ok, understandable. Unexpectedly it works if the new key is nested, although the result is the append lambda itself. This is probably not what the user wants:
merge{}{nested.new=append[];}
{nested={new=<LAMBDA>;};}
This seem inconsistent. Defining a new key with a merge function in the RHS should either always fail with a helpful message or always succeed.
I tend to prefer the latter because that would be consistent with the behavior we observe if no merge functions are used in the RHS (see first snippet).
The UX benefit would be that it always just works™.
One drawback could be that you can make less guarantees about the outcome from looking at the LHS. However, we can already not make any guarantees about which new keys will exist in the result since that depends on whether the new keys in the RHS use merge functions or not, and whether they are nested or not, which the LHS does not know. But the benefits of the data spine would still hold if data-merge accepted both scenarios in the RHS.
The real life problem is that you may not always know which keys exist in the LHS if you get it from elsewhere, like when writing a library. Currently it is necessary to pre-create the new keys in the LHS first to allow merging in possibly new keys with merge functions from the RHS (runnable example):
{inputs.data-merge.url="github:divnix/data-merge";outputs={nixpkgs,data-merge, ... }: {result=withdata-merge;letlhs={};# we may not know this valuerhs={new=append[];};# defeats the purpose of data-mergeprepopulatedLhs=nixpkgs.lib.recursiveUpdatelhs{new=lhs.newor[];};inmergeprepopulatedLhsrhs;# ok# in merge lhs rhs; # fails};}
The text was updated successfully, but these errors were encountered:
Since update [ <idx1> <idx2> ] [ { } { } ] can't be reasonably used without intimate knowledge of the lhs, I decided to keep the usage semantics of both decorators the same.
Defining new keys works as expected if you don't use merge functions in the RHS:
But if you use a merge function it fails:
Ok, understandable. Unexpectedly it works if the new key is nested, although the result is the
append
lambda itself. This is probably not what the user wants:This seem inconsistent. Defining a new key with a merge function in the RHS should either always fail with a helpful message or always succeed.
I tend to prefer the latter because that would be consistent with the behavior we observe if no merge functions are used in the RHS (see first snippet).
The UX benefit would be that it always just works™.
One drawback could be that you can make less guarantees about the outcome from looking at the LHS. However, we can already not make any guarantees about which new keys will exist in the result since that depends on whether the new keys in the RHS use merge functions or not, and whether they are nested or not, which the LHS does not know. But the benefits of the data spine would still hold if data-merge accepted both scenarios in the RHS.
The real life problem is that you may not always know which keys exist in the LHS if you get it from elsewhere, like when writing a library. Currently it is necessary to pre-create the new keys in the LHS first to allow merging in possibly new keys with merge functions from the RHS (runnable example):
The text was updated successfully, but these errors were encountered: