“Other languages” have this function also seem to be the same languages where every function is arity 1 (what you’d think of as an arity 3 function is just an arity 1 that returns a function that is arity 1 that returns a function that is arity 1 that return the result), and no language on the BEAM can work quite like that without a huge amount of preprocessing to ‘pack’ arity’s together if you want to work with the rest of the beam.

I think this proposal is tricky because, unlike identity/1, there isn’t an obvious arity that your return function should have. Should it be:

fn -> value end
or
fn _ -> value end
or
fn _, _ -> value end
... etc

Each of those has real scenarios where they’d be useful.

The other issue is that these two things do not have the same semantics: Function.constantly(code) and fn -> code end will behave differently depending on what code is. If code is DateTime.utc_now() then Function.constantly will return the same date time over and over, but fn -> DateTime.utc_now() end will return a new datetime each time it is invoked.

Nitpick: Function.constantly(value) is also not a shorter version, since it’s literally nine characters longer.

Clojure has a constantly, and it has functions that aren’t just syntactic sugar for arity-1 functions.

If we take maths as our source of truth(since most constructs of this kind come from there), then I’d argue the arity should be 1, based on notions from lambda calculus.

If we consider the expression λx.λy.x, giving it an x will result in an abstraction that, no matter what y we feed it, it will always return x. The resulting abstraction would be λx.y which is the constant function x↦y. The abstraction that produces such constant functions is the constant combinator K = λx.λy.x.

The identity combinator I is already incarnated in Function.identity, if the K combinator is implemented, we would only need to add the S combinator λfgx.fx(gx):

def substitution(f) do
  fn g ->
    fn x ->
      (f.(x)).(g.(x))
    end
  end
end

And this would complete the three combinators needed for SKI combinator calculus.

The other argument for K’s returned function to have an arity of 1, is that a lot of this work involves giving one argument at a time to partially apply those functions, and it just makes no sense to have more arguments. Having zero arguments also goes against the definition of x↦y.

Another observation is that such constant function is the return value, what’s being proposed is the combinator that produces it. Function.constantly(code) and fn -> code end will behave differently because the former is an invocation to the combinator, and the latter is the produced function. Moreover, if you give a function to Function.constantly/1, then expect the constant function to return the same function, not to evaluate it.

I don’t know what was the motivation behind the addition of Function.identity/1, but I’m not sure if it’s worth it to implement these combinators in elixir itself, or it’s best to leave it for userland code. I think that once you add one you’ll be tempted to add the others, and I don’t know if that’s the goal of the Function module.
I also understand that Elixir is a pragmatic language and academic purity is not it’s goal, but if we are going to implement these abstractions then we need to pick something that’s already been generalized and well understood, otherwise we would end up discussing which arity the function should have considering x, y and z practical examples, and for such cases I believe ad-hoc functions are the best.