Proposed resolution:

This wording is relative to N4791.

1. Change [func.not_fn] as indicated:

   template<class F> unspecified not_fn(F&& f);
   

   -1- In the text that follows:

   1. (1.1) — […]

   2. (1.2) — […]

   3. (1.3) — fd is the target object of g ([func.def]) of type FD direct-non-list-initialized withinitialized with the initializer (std::forward<F>(f)) ([dcl.init]),

   4. (1.4) — […]

2. Change [func.bind_front] as indicated:

   template <class F, class... Args>
   unspecified bind_front(F&& f, Args&&... args);
   

   -1- In the text that follows:

   1. (1.1) — […]

   2. (1.2) — […]

   3. (1.3) — fd is the target object of g ([func.def]) of type FD direct-non-list-initialized withinitialized with the initializer (std::forward<F>(f)) ([dcl.init]),

   4. (1.4) — […]

   5. (1.5) — bound_args is a pack of bound argument entities of g ([func.def]) of types BoundArgs..., direct-non-list-initialized withinitialized with initializers (std::forward<Args>(args))..., respectively, and

   6. (1.6) — […]

   -2- Mandates:

   is_constructible_v<FD, F> && is_move_constructible_v<FD> && 
   (is_constructible_v<BoundArgs, Args> && ...) && (is_move_constructible_v<BoundArgs> && ...)conjunction_v<is_constructible<FD, F>, is_move_constructible<FD>,
   is_constructible<BoundArgs, Args>..., is_move_constructible<BoundArgs>...>
   

   shall be true.

[ 2019-01-26 Priority to 0 and Status to Tentatively Ready after five positive votes on the reflector. ]

During the merge of the P0356R5, following "oddities" of the new wording was pointed out by Jens Maurer:

1. The initialization of the state entities of the bind_front/not_fn is specified using formulation "xx initialized with the initializer (yyy)". Per author knowledge this specification is correct, however inconsistent with the other parts of the of the standard, that direct-non-list-initialization term in such context.

2. The specification of the Mandates element for bind_front uses conjunction_v to specify conjunction of the requirements, while corresponding element of the not_fn specifies it using &&. As conjuction_v implies order of evaluation that is not necessary in this case (for every valid program, all provided traits must evaluate to true), it may be replaced with usage of fold expression with operator &&.