 
            I think we can discount 1a because it doesn't satisfy the stability
principles, right?
Out of the others, I would probably go with 1b or 3a as the most
predictable behaviours. I also like Simon's (4) (gated by an extension,
that we hope to enable in GHC2027).
Cheers
Simon
On Tue, 26 Mar 2024 at 09:35, Arnaud Spiwack 
Alright, so here are the plausible alternatives
1a. New type-class-based behaviour without extension 1b. New type-class-based behaviour gated by an extension 2. Just a warning (when main isn't at type IO () or IO Void) 3a. A warning + the new type-class-based behaviour gated by an extension. With the extension, types that don't implement the type class raise an error. 3b. A warning + the new type-class-based behaviour gated by an extension. With the extension, types that don't implement the type class raise a warning (which could have a different phrasing than without the extension).
Let's vote!
On Fri, 22 Mar 2024 at 15:30, Malte Ott
wrote: On 2024-03-22 08:58, Arnaud Spiwack wrote:
@Malte, in my opinion, with the extension on, types which are not covered by the type class should error out.
Ah, I see. Well, I am fine either way.
I just don’t see much value in deciding for the user which code problems are unacceptable. Especially since this will make the corresponding language extension more breaking and thus harder to make the default. Others have voiced similar opinions in the GitHub thread.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee