We come to the same conclusion though: explicitly enabled, on a per-module basis. 
2 Likes
In that case, perhaps an example might be useful. Of course you can overdo it (pun intended) but especially for patterns like
I find it super useful. Same for writing lucid2, please look at how many $ you have to use, literally a fortune worth of syntactical noise!
For people who don’t like OverloadedStrings… how do you feel about numeric literals being overloaded by default? I was going to suggest that we add NoOverloadedNumbers which would make literals always be Integers as a joke… but actually I kind of like the idea!
9 Likes
Probably getting off-topic here, so maybe we spin this out into a separate thread, but - how much have you tried to use BlockArguments in anger? Like others, I find it indispensable and don’t really have any recollection of it being confusing/giving me weird syntax errors/etc. It’s always felt perfectly natural from the get-go. I’m curious if the syntactically baffling bit comes from having trialed it and having a poor experience by the end, or just comes from purely reading code?
12 Likes
I haven’t used it myself. I’ve just read code that uses it and it looks so alien that I feel discouraged from it. I also don’t find using $ inconvenient at all. I’ve changed my mind on plenty of things before though. This may become one of them.
3 Likes
I think the best explanation for BlockArguments's aversion is that it feels like someone is writting a very long text without commas. In this analogy $ is the comma, in case I wasn’t very clear 
2 Likes
I’d use BlockArguments if after enabling it there was a tool (like hlint) detecting redundant $ and telling me to remove them.
2 Likes
The do and the \ are already the comma, no need to put two commata in a row.
6 Likes
Just to clarify, does DisambiguateRecordFields works now or not ? Last time I tried to do something like
data A = A { x :: Int }
data B = B { x :: Int }
a = A 3
a' = a { x = 2 }
Wouldn’t work.
It won’t do type dependent name resolution, i.e. it only works if you use the constructor directly:
data A = A { x :: Int }
data B = B { x :: Int }
a = A { x = 2 }
even if I do a { x = 2 } :: A ? (or something ?)
In that case I don’t see the point of having it.
What about MultiWayIf, surely it is as inoffensive as ,let’s lambdaCase and Co …
7 Likes
Can we vote AGAINST (OverloadedStrings for example) ?
3 Likes
As long as you don’t want to vote against everything, you vote against by not checking a box At least that’s how I interpret the results. (Yes, maybe it would be more precise to also have “don’t care” and “don’t know”. But to get a Stimmungsbild this should be enough I hope.)
4 Likes
I voted yes for the option I like and no for the one I don’t have an opinion.
However I want to be able to vote against OverloadedString because it breaks exisiting code heavily.
This mean I have to turn the full GHC2024 off all together (and not benefit from all the option I voted for).
You could do
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE NoOverloadedStrings #-}
2 Likes
I didn’t think of that 
but this is because IMHO ultimately extensions which have been integrated into HaskellXX should be just part of the language with no way to disable them. If everybody agree that for example LambdaCase is good and harmless (people don’t have to use it after all) what is the point of having a NoLambdaCase extension ?
Does it alleviate your worries that OverloadedStrings is currently not on the ballot and so far I haven’t seen anyone nominate it?
2 Likes
Well it is on your list of option to vote for. I assumed that if enough people voted for it, you might press to include it. Otherwise what was a point of including it ???
1 Like