Tuples

fn x =
    let
        ( a, b ) =
            something x
    in
    ( a, b )
-->
fn x =
    something x

Custom types

fn x =
    let
        (A a) =
            something x
    in
    A a
-->
fn x =
    something x

At the moment, the rule doesn't report the destructuring of single variant constructors when we don't know whether the type has any phantom types (as that could be the purpose of the destructuring).

This correctly doesn't get reported.

type A b = A String
a = let (A b) = xyz
    in A b

But if the outer function has a type signature, and the return type is the same as the type of the value, then there is no need to destructure the value.

module A exposing (..)
type A b = A String

-- should be simplified
xyz : A String
xyz = -- ...

-- Can be simplified
a : A String
a n = let (A b) = xyz
    in A b

This probably needs type inference to work correctly.

Example:

fn x =
    let
        { a, b } =
            value
    in
    { a = a, b = b }
-->
fn x =
    value

We can maybe push a bit further and simplify the following as well.

fn x =
    let
        result =
            value
    in
    { a = result.a, b = result.b }
-->
fn x =
    value

To work well, we need to know whether the set of keys in value are the exact same as the one in the return value. If value has a c field, then this destructuring means something. Type inference would help, but we can take a look at the function definitions, and ignore where we don't know well enough. If we can't infer the set of keys, we shouldn't report anything.

The order of the keys does NOT have to be the same, compared to tuples where the order does matter.

At the moment, the rule doesn't report the destructuring of single variant constructors when we don't know whether the type has any phantom types (as that could be the purpose of the destructuring).

This correctly doesn't get reported.

type A b = A String
a = let (A b) = xyz
    in A b

but the heuristic we use is to only check whether the type has type variables. We are not checking whether the type variable is actually a phantom one or not.

module A exposing (..)
type A b = A b
-- should be simplified
a = let (A b) = xyz
    in A b

There may some edge cases to figure out where this might be change things? For instance, what if the type is a phantom type by transition (used as a type variable to another type where it is a phantom type)? To be explored.

At the moment, the rule doesn't report the destructuring of single variant constructors when we don't know whether the type has any phantom types (as that could be the purpose of the destructuring).

This correctly doesn't get reported.

type A b = A String
a = let (A b) = xyz
    in A b

but we only gather information about constructors from the current module. If a single-variant custom type from another module or from a dependency is used in such a way when it doesn't have a phantom type variable, then we should report it.

module SomeModule exposing (A(..))
type A b = A String

-- other module
import SomeModule exposing (A(..))
-- should be simplified
a = let (A b) = xyz
    in A b

What the rule should do:

Report let functions that are defined as the partial application of a function, and only used directly in the body of the let expression.

What problems does it solve:

Unnecessary variable declarations

Example of things the rule would report:

fn value =
  let
    a =
      List.map fn
  in
  a data
-->
fn value =
  List.map fn data

Example of things the rule would not report:

The rule should only report when the value is a direct function call. It shouldn't report it when the function is more complex. Basically, we shouldn't have to add parentheses for this to work.

fn value =
  let
    a =
      if condition then
        List.map fn
      else
        identity
  in
  a data

If the function has arguments, we should not report it, even if it means the same thing

fn value =
  let
    a data_ =
      List.map fn data_
  in
  a data

If the function is referenced anywhere else in the let declarations or let body, then we should not apply this change.

I am looking for:

Someone to implement it

module A exposing (..)
a = let value_ = 1
    in value_

Should get a suggested fix:

module A exposing (..)
a = let value = 1
    in value

fn value =
  let
    a =
      something

    something =
      1
  in
  something
--> should NOT transform to
fn value =
  let
    a =
      something
  in
  1

The above should not be reported. Even though a is necessarily unused (at least for the current implementation), it may still exist for a bit, which will cause the code not to compile anymore. It's likely that NoUnused.Variables is enabled and will fix the issue anyway, but we shouldn't rely on this.