#1637, add a typeApplications option for restricted functions

[NorfairKing]

Revives #1667 (closed stale), addressing #1637.

Function restrictions gain a typeApplications field, so a silent change to an inferred type can't change behaviour unnoticed:

- functions:
  - {name: show, typeApplications: required}     # >= 1 type argument
  - {name: fromIntegral, typeApplications: 2}    # >= N type arguments
  - {name: id, typeApplications: forbidden}      # none

Also applies to constructors in prefix patterns (Just @Int x).

Semantics

• Only positions that can carry a type application are checked: expression heads and prefix constructor patterns. Type signatures, class method signatures, record fields, binders, infix operators and sections are never flagged, since the advice couldn't be followed there.
• @_ doesn't count towards required, since it leaves the type as inferred as writing nothing — fromIntegral @_ @_ is still flagged. It does count towards forbidden.
• When several rules match one name the last-declared wins. Merging is no use: a name can't both require and forbid a type application.

Testing

hlint --test passes. tests/type_applications.test covers required/forbidden/count, constructor patterns, each non-call position above, wildcards in both modes, and conflicting rules in both declaration orders.

Changes since review

Per @zliu41's review:

• the check no longer fires in positions that can't carry a type application (type signatures, class method signatures, record fields, binders, infix operators, sections)
• @_ no longer counts towards required, so fromIntegral @_ @_ is flagged
• overlapping rules resolve by last-declared, rather than an arbitrary merge
• tests for each of the above, including the qualified/unqualified fromList case in both declaration orders

---

Written by Claude, reviewed and signed-off on by @NorfairKing

[NorfairKing]

Gentle ping. How would I go about getting this merged?

[NorfairKing]

CC @ndmitchell I'm not sure who to ping.

[zliu41]

A name can appear in different places like declarations, patterns, type signatures etc. Need to test that the hint is only triggered when it should - the current tests aren't sufficient.

{name: fromIntegral, typeApplications: 2}

Does this allow fromIntegerl @_ @_? Either way, need test coverage.

[zliu41]

What happens if one of the two fromList is unqualified?

[NorfairKing]

Both rules matched and the merge decided it, so declaration order had no effect at all. Same root cause as your Semigroup comment, so it's fixed the same way: the last-declared rule now wins.

With Data.Map.fromList: required then fromList: forbidden, an unqualified fromList from Data.Map ends up forbidden from carrying one; swap the order and it's required. Both directions are pinned in tests/type_applications.test, along with the qualified-vs-qualified pair.

[zliu41]

This is quite arbitrary. How about whichever rule declared later wins?

[NorfairKing]

Agreed, and done.

It needed a little more than swapping the operator: restrictions builds a Map and findFunction sconcats Map.elems, so by merge time the declaration order was gone entirely. Rules now carry their position in the settings and the payload is Maybe (Max (Arg Int RestrictTypeApp)), so the latest wins across both the same-key union and the cross-module sconcat. The ad-hoc Semigroup RestrictTypeApp is gone. Tested in both declaration orders.

[NorfairKing]

Thanks, both were real.

Non-call positions. You were right that the tests weren't sufficient. It was firing on top-level type signatures, class method signatures, record field declarations and argument binders, and on a further sweep also on infix operators, sections, infix constructor patterns and record-syntax constructor patterns. None of those can carry a type application, so the advice couldn't be followed. The check now works off a positive set of sites — expression heads and prefix constructor patterns — instead of every RdrName in the declaration, and tests/type_applications.test has a case per position.

One case I left firing and documented rather than fixed: a locally bound name shadowing a restricted one, since HLint doesn't resolve local binders. That matches the existing Avoid restricted function behaviour.

fromIntegral @_ @_. It did pass, which defeats the point of #1637 since @_ fixes nothing. It no longer counts towards required, so that's now flagged. It still counts towards forbidden, which asks that no visible type application is written at all. Tests for @_ @_, @Int @_ and @Int @Integer under 2, and @_ under forbidden.

[NorfairKing]

@tomjaguarpaw this is the implementation of the haskell/core-libraries-committee#314; which you asked to be CC-ed on.

[NorfairKing]

Gentle ping

[zliu41]

Please resolve conflicts

[NorfairKing]

❤️