Hi @claudia_giannoni @Gary_Verhaegen. To clarify on
The syntax Receipt with ..
is valid, whereas the syntax receipt with ..
is not.
[…]
I’m not sure if there’s a fundamental reason to disallow receipt with ..
, but it does make sense to me that if you’re going to override all of the fields of receipt
, you’re better off creating a brand new one anyway.
The emphasized part really sums it up from the user’s point of view.
The more fundamental reason is that the ..
in a record construction expression gets expanded at compile time to assignments for the given record constructor’s fields which are missing in the braces. For example, given the type Rec
data Rec = Rec with
a : Int
b : Text
c : Bool
d : Party
deriving (Eq, Ord, Show)
r = Rec with { a = 42, b = "hello", .. }
{- expands to
r = Rec with { a = 42, b = "hello", c = c, d = d }
-}
Where c
and d
refer to whatever bindings are in scope.
However, when the ..
appears in a record update expression, there’s no way to know at compile time what constructor was used for the value and thus what fields are missing assignments. When the type is defined as a record this might not be obvious, but consider a type like
data Sum
= SumAB with
a : Int
b : Text
| SumAC with
a : Int
c : Party
deriving (Eq, Ord, Show)
and a value val : Sum
. Then, for the expression val { a = 100, .. }
, there’s no way to know at compile time whether ..
should expand to b = b
or c = c
, because it’s not known whether val
is a SumAB
or a SumAC
.