JavaScript ES6: Test for arrow function, built-in function, regular function?

Believe it or not…

Testing for presence of “=>” in string representation of a function is likely the most reliable way (but not 100%).

Obviously we can’t test against either of 2 conditions you mentioned — lack of prototype property and lack of [[Construct]] as that might give false positives with either host objects or built-in ones that lack [[Construct]] (Math.floor, JSON.parse, etc.)

We could, however, use good old Function.prototype.toString to check if function representation contains “=>”.

Now, I’ve always recommended against using Function.prototype.toString (so-called function decompilation) due to its implementation-dependent and historically unreliable nature (more details in State of function decompilation in Javascript).

But ES6 actually tries to enforce rules on the way (at least) built-in and “user-created” (for the lack of better term) functions are represented.

2. If Type(func) is Object and is either a Built-in function object or
   has an [[ECMAScriptCode]] internal slot, then

   a. Return an implementation-dependent String source code representation of func. The representation must conform to the rules below.

…

toString Representation Requirements:

• The string representation must have the syntax of a FunctionDeclaration FunctionExpression, GeneratorDeclaration,
  GeneratorExpession, ClassDeclaration, ClassExpression, ArrowFunction,
  MethodDefinition, or GeneratorMethod depending upon the actual
  characteristics of the object.

• The use and placement of white space, line terminators, and semicolons within the representation String is
  implementation-dependent.

• If the object was defined using ECMAScript code and the returned string representation is not in the form of a MethodDefinition or
  GeneratorMethod then the representation must be such that if the
  string is evaluated, using eval in a lexical context that is
  equivalent to the lexical context used to create the original object,
  it will result in a new functionally equivalent object. In that case
  the returned source code must not mention freely any variables that
  were not mentioned freely by the original function’s source code, even
  if these “extra” names were originally in scope.

• If the implementation cannot produce a source code string that meets these criteria then it must return a string for which eval will throw
  a SyntaxError exception.

I highlighted relevant chunks.

Arrow functions have internal [[ECMAScriptCode]] (which you can track from 14.2.17 — evaluation of arrow function – to FunctionCreate to FunctionInitialize).

This means they must conform to ArrowFunction syntax:

ArrowFunction[In, Yield] :
  ArrowParameters[?Yield] [no LineTerminator here] => ConciseBody[?In]

..which means they must have => in Function.prototype.toString‘s output.

You’ll obviously need to ensure “=>” follows ArrowParameters and is not just something present in FunctionBody:

function f() { return "=>" }

As for reliability — remember that this behavior is/might not be supported by any/all engines at the moment and that host objects’ representation might lie (despite specs efforts) for whatever reasons.