Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
There seem to be two motivations.
Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards. It may not be pretty to divide things up
so fine, but it’s not new.
If there are alternative suggestions, let’s hear them.
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki@gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee@haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
I do think that reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.