Disallow partial record construction

[yav]

View: https://github.com/yav/rfcs/blob/no-partial-records/texts/no-partial-records.rst

[jwiegley]

Should this be disallowed, or left as a warning from the compiler? Is there a larger goal we have in mind that prompts such a restriction at the language level?

[yav]

I think it should be disallowed, as it is a common source of errors, at least for me. Also, I can't think of any particularly compelling use cases of allowing such partial records---it would be interesting if we could find the original reasoning for allowing them in the first place.

[jwiegley]

I do think we need more input than its effect on one person who doesn't want the feature...

[yav]

Of course---I added this proposal because someone suggested at it during the State of Haskell discussion at the Haskell Symposium. Please do add additional pros and cons if you know of any.

[goldfirere]

I think we can have our cake and eat it too on this one: we can remove partial records from the standard but still specify a standardized extension to re-enable them. GHC can have the extension on by default until we're ready to make a change there. In general, I like this proposal.

Note: I misunderstood what a "partial record" was when reading this the first time. I thought it was a record type with multiple constructors defining different sets of fields. This proposal is about partial record construction.

[jwiegley]

After reading @goldfirere 's suggestion, I now fully support removal.

[thoughtpolice]

I'm 👍 on this, following @goldfirere's suggestions. -XPartialRecordFields sounds like an OK name too (to get out in front of that bikeshed).

Note: I misunderstood what a "partial record" was when reading this the first time. I thought it was a record type with multiple constructors defining different sets of fields. This proposal is about partial record construction.

You aren't alone, that was my initial interpretation too. But this proposal is still good. :) Then again, if we ever do end up addressing that wart, we may need another extension. Like -XPartialRecordConstructorFields...

[goldfirere]

Might I suggest -XIncompleteRecords? I don't much like -XPartialRecordFields as the record fields aren't what's partial. (That makes me think back to fields that exist in some constructors but not others.)

[thoughtpolice]

I'm fine with that naming, too.

Also, side note: we need to actually implement this in GHC itself still. It's an obvious and trivial change (2-3 actual lines, ~50 lines of docs). There isn't really a label for this on the tracker yet, though. I'll add one to this issue if I can.

[blamario]

I like -XIncompleteRecords the best, as far as naming goes. But if there is any name, it's for a command-line option and LANGUAGE pragma extension, right?

I'm against breaking backward compatibility for a such small gain, so -XIncompleteRecords should be the default, in my opinion, while -XNoIncomleteRecords would disallow partial record constructions. This would go against the grain of the existing GHC language extensions, though.

[goldfirere]

There is precedent for extensions that are on-by-default -- the most popular of which is -XMonomorphismRestriction. There are several others (like -XImplicitPrelude).

I think the idea would be that Haskell2020 would disallow incomplete records, implying that -XHaskell2020 would entail -XNoIncompleteRecords. But GHC is free to maintain whatever defaults it likes, and I personally would like it to keep -XIncompleteRecords on by default for some time.

[AndreasPK]

There is one legitimate use case.

When extending record based types code depending only on that partial subset continues working with both versions.

The other one is laziness to fill Constructors with undefined in many arguments. Something that might be better solved by tooling though.