existing-records.md

@@ -309,6 +309,74 @@ foo x@(C2 {}) = x {f1 = 2}
 foo x         = x {~f1, f2 = f2 x + 1}
 ```
 
+### Comment
+
+
+
+(Comment from Niklas Broberg)
+
+
+
+This suggestion would go a long way to alleviate the burden of
+boiler-plate coding. It is a conservative extension, and it is
+intuitive at that. Indeed I believe I have written code with the
+suggested update mechanism many times without thinking on the type
+mismatch (and been beaten on my fingers by the compiler of course).
+:-)
+
+
+
+Is this really necessary? Adding `~` seems less intuitive to me than
+just writing
+
+
+```wiki
+foo :: T a -> T Int
+foo x@(C1 {}) = x {f1 = 1}
+foo x@(C2 {}) = x {f1 = 2}
+foo x         = x
+```
+
+
+or
+
+
+```wiki
+foo x = x {f2 = f2 x + 1}
+```
+
+
+for the last example. From an implementor's point of view, if we
+expect the proper coercions to be inferred by the type checker it
+would still have to check that there are indeed no more fields than
+other than `f1` that mention the parameter `a`, and also that there
+are no more constructors that mention `f1`. Wouldn't it be just as
+simple to assert that for all the fields that mention `a`, none of
+these appear in any of the remaining constructors?
+
+
+
+On the other hand pattern matching would certainly be more expressive
+if `~` is added, so perhaps adding it has merit of its own. If we
+write
+
+
+```wiki
+foo :: T a -> T Int
+foo x@(C1 {}) = x {f1 = 1}
+foo x@(C2 {}) = x {f1 = 2}
+foo x         = x {~f1}
+```
+
+
+there could still be more constructors in T a that do mention the `f1`
+field, but there is no matching clause for them in the definition of
+`foo`. But I would see that as a second separate proposal, e.g. a
+Proposal for Negation in Record Pattern Matching. Sure it would fit
+very well with the Polymorphic record update discussed here, but I
+would think they should be treated separately.
+
+
 # Meta-Proposal