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
However, if I wrap that yield inside a User Op and try to pass this from main scope into the Op's this using the ... spread operator, the primitive value gets dropped.
Admittedly, the docs do call out how the use of the spread operator means that only records will be expected:
...user-defined operators may use the spread operator ... to indicate that the operator expects a record value whose key/values will be expanded as entries in the operator's this record value.
However, if we start from the design principle stated in #4649, we may want to avoid having this limitation. When discussing as a team, there were two reactions:
If we kept the current behavior, it could be improved by throwing an error when such values are dropped rather than its current silence
We may instead change to an approach that allows this to passed in from the main scope in a way that primitive values don't get dropped
The text was updated successfully, but these errors were encountered:
Of the two likely approaches described above, the changes in linked PR #4650 took the latter approach of allowing this to be carried through into the User Op such that primitive values are no longer dropped. Updating the repro steps to align with the revised syntax, we now see:
Repro is with Zed commit 2314053.
The main scope is able to process both primitive and complex values as
this
, e.g.:However, if I wrap that
yield
inside a User Op and try to passthis
from main scope into the Op'sthis
using the...
spread operator, the primitive value gets dropped.Once a user is aware of this limitation, they could work around it by passing the main scope's
this
into a named parameter, e.g.:Admittedly, the docs do call out how the use of the spread operator means that only records will be expected:
However, if we start from the design principle stated in #4649, we may want to avoid having this limitation. When discussing as a team, there were two reactions:
error
when such values are dropped rather than its current silencethis
to passed in from the main scope in a way that primitive values don't get droppedThe text was updated successfully, but these errors were encountered: