Why does mkFlagName not convert the string to lower-case?

[peti]

My understanding is that flag names are supposed to be case-less, i.e. they are normalized to all-lowercase in the Parsec instance of FlagName. This feels like an awkward place to do this, however. Why doesn't that conversion take place in mkFlagName? As it is now, a construct like

mkFlagAssignment [(mkFlagName "foo", True), (mkFlagName "FOO", True), (mkFlagName "Foo", False)]

gives

fromList [(FlagName "FOO",(1,True)),(FlagName "Foo",(1,False)),(FlagName "foo",(1,True))]

instead of:

fromList [(FlagName "foo",(3,False))]

That doesn't feel right?

[phadej]

cc @hvr

[23Skidoo]

@hvr Ping.

[phadej]

Caseness is tricky (it's dependent on Unicode standard), the differences are very subtle. I'd rather make flags case-sensitive in cabal-version: 3.0

(Hackage doesn't accept non-ascii flags, but that's its choice)

EDIT case-sensitive, not insensitve in 3.0

[peti]

I've extended the test suite in #5082 to verify that flag names are case-less.

Personally, I believe flag names should be case-less (and they should be constrained to plain ASCII, i.e. no Unicode). A change that behavior now or in the future would be a rather nasty surprise to everyone who's relied on the current behavior in their scripts and Cabal config files.

[hvr]

@phadej I'd limit case-insensitivity to the ASCII subset; but everything outside the ASCII subset ought to be case-sensitive; DNS case-folding does something like that as well. However, I'd rather make flags completely case-sensitive in cabal-version:3.0 to make things more consistent with the case-sensitivity of package names, and eschew the subtle issues (e.g. broken Leibniz equality expectations) of case-folding altogether.

[BardurArantsson]

Why are we not doing the obvious here and limiting the flag names to ASCII? (Plus, case folding)

Is there any plausible use case for non-ASCII flags, especially given that Hackage doesn't accept them per @phadej ?

[23Skidoo]

Yes, it was discussed before: #4696 (comment).

[BardurArantsson]

I don't see much of an argument there, I'm afraid.

It's just "I want to be able to do X". There doesn't seem to be any reasoning as to why the restriction would be a problem. Yes, I understand that some programming communities may want to prefer being able to use whatever characters they want, but I can't see it would actually be a problem to just say "sorry, not supported".

This seems to me to letting perfect be the enemy of good and already seems to have caused quite a bit of frustration; see e.g. #5082

Oh well. (I'm not the one who's frustrated by this, but it seems pretty absurd on the face of it to drag our collective feet for such an incredibly marginal feature where simply saying "case insensitive ascii" would suffice.)

[peti]

Personally, I think the philosophizing about the design space for Cabal 3.0 is great and I am all for it. Let's go full Unicode everywhere. Looks good to me!

What I don't understand is why any of this stands in the way of fixing issues that exist today. That frustrated me. I care more about what Cabal 2.2.x is doing than I care about some other major release that may or may not come out 3 years down the road. I too think that this conversation is a pretty good example of letting perfect be the enemy of good.

[BardurArantsson]

Indeed, I don't see any problem with thinking ahead, but holding up working code/fixes because we might do a theoretically better version in the future is a Bad Idea(TM). If a fix needs to be reverted later, fine let's do that! It's usually a complete non-issue in any sane development process to do that. Of course one shouldn't be completely reckless in accepting anything and everything (nor if there are concrete plans for a different approach), but I mean...

I also see this type of thing being an increasingly problematic part of the Cabal development process, regardless of what particular feature we're talking about. (Hence why I brought it up.)