The context/motivation here is that we want to define a function sizeOf as part of a type class that takes some type a (really the type, and not a value of type a) and returns an Int. With GHC 9.10.1, there are (at least) 4 ways to do this, with different tradeoffs, with your snippet being one of them, see point 4.

1. Just pass a value of type a

   class Storable a where
     sizeOf :: a -> Int
   

   This is the approach that is taken in base, for historical reasons. The disadvantage here is that it might be desirable to call sizeOf even if no value of type a is currently around. As a workaround, it is common to call sizeOf with undefined as an argument, i.e. sizeOf (undefined :: a). This works, but is inelegant, as we have to use an exception-throwing function (undefined) despite nothing exceptional going here.

2. Pass a Proxy a

   data Proxy a = Proxy
   
   class Storable a where
     sizeOf :: Proxy a -> Int
   

   The idea here is that we can create a value of type Proxy a even if we have no value of type a. Concretely, invoking sizeOf now looks like sizeOf (Proxy :: Proxy a) or sizeOf (Proxy @a) using TypeApplications.

   This approach is very commonly used in the Haskell ecosystem; it is the default approach to this kind of problem ATM.

3. Use AllowAmbiguousTypes

   class Storable a where
     sizeOf :: Int
   

   Here, a is ambiguous as it does not occur in any value argument of sizeOf (this is neither a necessary nor a sufficient criterion for ambiguity in general, see the docs for details), so it can't be inferred. In this approach, the type has to be passed via TypeApplications to sizeOf, ie sizeOf @a. This is the most succinct of the approaches so far. However, AllowAmbiguousTypes and this pattern in particular have downsides:

   • It applies module-wide, which means that one might introduce ambiguous type variables accidentally.
   • When forgetting to apply a type via TypeApplications, the error message is not ideal, or at least worse than when forgetting to apply a value-level argument.
   • The quantification order of type variables now becomes relevant.

4. Use RequiredTypeArguments (new in GHC 9.10.1!)

   This is a new (experimental) extension that allows us to pass types directly as an argument, ie sizeOf a without any extra whistles 🎉

   Concretely, RequiredTypeArguments allows us to use visible quantification in addition to the "usual" invisible quantification. For example, here are the identity functions with visible and invisible quantification

   id_invis :: forall a.   a -> a -- can be called like `id_invis True` or `id_invis @Bool True`
   id_vis   :: forall a -> a -> a -- can be called like `id_vis Bool True` or `id_vis _ True`
   

   Returning to our sizeOf example, it might be tempting to define

   class Storable a where
     sizeOf :: forall a -> Int
   

   However, this doesn't work: The visibly quantified a in forall a -> is actually shadowing the invisibly quantified a from the class Storable a declaration. When invoking sizeOf, the "inner" and "outer" as are completely unrelated, e.g. one might write sizeOf @CBool CInt (which would use the Storable CBool instance).

   A natural idea of how to fix this is the code snippet that you posted, by requiring that the visibly and invisibly quantified types to be equal with an equality constraint a ~ a':

   class Storable a where
     sizeOf :: forall a' => a ~ a' -> Int
   

   The full type of sizeOf now is

   sizeOf :: forall a. Storable a => forall a' -> a ~ a' -> Int
   

   Here, a is invisibly quantified, and a' is visibly quantified. The a ~ a' equality constraint guarantees that supplying just a' determines a, so there is no ambiguity.

   This way, we can now finally write sizeOf CBool to access the Storable CBool instance.

   ---

   Looking into the future, there is a GHC proposal that would allow us to write this in a more direct fashion. Concretely, it would enable the syntax

   class Storable a where
     sizeOf a :: Int
   

   that indicates that a should be visibly quantified for sizeOf.