3.1 Details

If an parameters list starts with double parentheses ((, then all single identifier are not types, but variables instead:

auto something(string, vector);   //< declaration of function with two parameters of type `string` and `vector`.
                                  // param names are omitted
auto something((string, vector)); //< declaration of function with two parameters of deduced type.
                                  // param names are `string` and `vector` (this proposal)

Using multiple identifiers results in exactly the same declarations no matter if single or double parentheses are used:

auto something(vector v);   //< same declarations
auto something((vector v)); //<
auto something(const vector& v);   //< same declarations
auto something((const vector& v)); //<

Mixing single and multiple identifiers is possible:

auto something((string, const vector& v)); //< `string` is of deduced type, `v` is of const vector&

In other words, types are optional. Parameters of deduced type are templated parameters. Functions and lambdas, containing such parameters are templates. The above declaration is equivalent to:

template<class T>
auto something(T <qualifiers> string, const vector& v);

Function template. <qualifiers> are discussed in Part 2.

Mixing with regular template parameters is also possible:

template<class T> void func((T a, b)); 
[]<class T>((T a, b)) {};               

// equivalent to
template<class T, class U> void func(T a, U <qualifiers> b); 
[]<class T, class U>(T a, U <qualifiers> b) {}; 

As well as omitting identifiers, partially or completely:

void func((,));
[]((a,,c,)) {}; 

// equivalent to
template<class T, class U> void func(T <qualifiers>, U <qualifiers>);
[](auto <qualifiers> a, auto <qualifiers>, auto <qualifiers> c, auto <qualifiers>) {}; 

If there are no identifiers and no commas, the list is empty:

void func(());

// equivalent to
void func();

If the parameters list does not contain deduced types, or extra commas, the declaration is not a template:

void func((T a, U b)); 

// equivalent to
void func(T a, U b); 

Default arguments can be supplied as usual:

void func((a = 12, b = "hello"s)); 

// equivalent to
template<class T=int, class U=std::string> void func(T <qualifiers> = 12, U <qualifiers> b = "hello"s);

The syntax can not be used to declare function pointers or signatures:

// using FuncPtr = void(*)((string));                 // error
// using FuncPtr = void(*)((std::string));            // error
// using FuncPtr = void(*)((const std::string&));     // error

The main reason to disallow this is to be consistent with current auto rules:

// using FuncPtr = void(*)(auto); // already an error

Although, it could be argued auto in using declaration can be allowed to mean a template param for the using declaration itself:

template<class T>
using FuncPtr = void(*)(T);

As this is completely out of scope for the current proposal, double parentheses are allowed only where auto placeholder is allowed.
Similarly, function declarations inside a block are not allowed :

void f() 
{
  []((string)){};             //< Lambda: OK
//  auto something((string)); //< Function: error
}

This should come to no surprise, because function templates in block scope are not possible today. However, even if we allow these, double parenths declarations will still be disallowed, because it will be a breaking change: auto something((string)); is already a valid expression (a constructor call to something object, taking string variable as an argument).

This covers Part 1 of the proposal - allow a 3th way of declaring function templates, one that will let us to omit the type (or its placeholder in the form of auto) completely. Part 2 will discuss the options we have with regard to the deduced type and its decorations.

3.2 Example

As stated in the beginning, getting rid of the parameters type is one of the best “bang for the buck” in the attempt to lower verbosity:

// given
struct fruit {...};
std::vector<std::string> fruits{"apples", "oranges","cherries"};
std::vector<std::vector<fruit>> baskets{...};

std::transform(fruits.begin(), fruits.end(), baskets.begin(), fruits.begin(),
// from
  [](const std::string& fruit, const std::vector<fruit>& basket) { return fruit + ": " + std::to_string(basket.size()); 
// or
  [](const auto& fruit, const auto& basket) { return fruit + ": " + std::to_string(basket.size()); 
// to (this proposal)
  []((fruit, basket)) { return fruit + ": " + std::to_string(basket.size());
});

// `auto&&` is discussed in Part 2

If we take a theoretical “abbreviated body”, the gains are much less in terms of reducing verbosity, at least in this example, though I would argue, the example is fairly representative in general:

std::transform(fruits.begin(), fruits.end(), baskets.begin(), fruits.begin(),
  [](const auto& fruit, const auto& basket) { return fruit + ": " + std::to_string(basket.size(); 
});
std::transform(fruits.begin(), fruits.end(), baskets.begin(), fruits.begin(),
  [](const auto& fruit, const auto& basket) => fruit + ": " + std::to_string(basket.size() 
);

As you can see, if we ignore the generic, forwarding case, the gains are almost non-existent - a constant 7 characters total, 6 of them from return, 1 for the semicolon.
This is not to say the generic case is to be ignored - quite the contrary. Most of the benefits in an “abbreviated lambdas” will come from a new, smarter “abbreviated body”. An “abbreviated body” will solve more problems then simply limiting verbosity as it will lower the complexity of advanced topics that only look simple on a first glance. This paper is not against any “abbreviated body” solutions and it does not block or contradict ony of them.
In any case however, “abbreviated parameters” have enough practical benefit for “abbreviating” the lambda expression as a whole to be worth pursuing on their own.

3.3 Related Work

Using duplicated symbols to denote a different entity is not new. In fact, it can be traced back to (at least) C:

• We have multiple operators that have double versions ||, &&, ++, --, <<, >>, ==;
• We have two types of references, & and &&, expressed via duplication of the symbol;
• We have both lambda capture - [something] - and attributes - [[something]];
• We have both : and ::;
• We have . and ...;

I would argue, symbol duplications is at this point a natural way to introduce new meaning without new symbols.

5.1 Downsides of auto&&

std::transform(fruits.begin(), fruits.end(), baskets.begin(), fruits.begin(),
  [](auto&& fruit, auto&& basket) { return fruit += ": " + std::to_string(basket.size());
});

std::sort(fruits.begin(), fruits.end(),
    [](auto&& lhs, auto&& rhs) { return lhs.price() < rhs.price(); }
);

[](a, b){ a++; b += a; return b;}

[](auto a, auto b){ a++; b += a; return b;}

[]((a)){ return some_func(std::forward<decltype(a)>(a)); }

[](const auto& a, const auto& b){...}

[]((const a, const b)){...}

5.2 Proposed solution

This paper suggests, a const reference and/or const copy as the best options for the deduced type.
More specifically, const reference to be the default, but, if deemed feasible, allow optimizers to use copy instead for improved performance.

std::string s;
std::vector<std::string> v;

std::for_each(s.begin(), s.end(), []((c)){ ... }); //< decltype(c) is `const char`
std::for_each(v.begin(), v.end(), []((s)){ ... }); //< decltype(s) is `const std::sting&`

Because in both cases we are dealing with a const arg. the effect of the transformation to copy will be close to invisible to the user. The only observable side-effect will be if the user, or a subroutine, takes and stores the address of the argument, with the assumption, its lifetime is greater then the lambda itself. In that case the address can become invalid or not, depending on the argument type.
How much this is a problem in practice is hard to jude, but this paper argues, it is extremely unlikely, a user will intentionally take the address of a param (or call a function which does so) AND use a signature, which does not have reference/pointer symbol on the param:

void func((arg)) { persistAddrOf(&arg); ... } //< Unrealistic scenario

It is unlikely, the user expects, arg storage to outlive the call to func.

This goes back to the fact - there are no hidden references in C++. Sure, arg could be a reference, but no reason for the user to expect that. There is no previous experience to create such expectations!
Also, the implementation can be such that, the user can query and/or assert if the conversion to reference will take place. Something along the lines of static_assert(sizeof(arg) < TO_CREF_THRESHOLD). This will allow 100% safe code, albeit with increased complexity.

Having said that, I do see this feature as potentially controversial, that is why, it is suggested only if feasible - const reference alone is good enough default. Besides, if the user wants to have a copy instead, a simple auto is still an option.

While on the subject of copying, why aren’t the arguments passed by copy, the way they are passed in functions and lambdas already, if there are no cvref decorations?
There are multiple arguments against that.

• Expensive to copy big objects.
• Verbose to get immutability back, even more so to get both reference and immutability.
• Not really possible to implement “maybe-reference”, because this will change how the function/lambda works in a dangerous way. We can get away having “maybe-reference” exclusively because immutability, which makes the transformation safe, as long as one operates on the param alone, not its address.

The pro-arguments are much weaker:

• No hidden immutability.
• No hidden const reference.
• No hidden change of param address. (In case “maybe-reference” is implemented)

The first argument is weak, because we have a precedent with lambda captures. Captures can be though as “arguments, passed on lambda definition”. Not only that, but the immutability of lambdas has overwillingly positive reception in the community. In a way, by making the parameters of a lambda immutable, we increase the overall consistency of the lambda expression as a whole - now all arguments, passed to a lambda, either on definition or call time, are immutable.
The second argument is also weak, because it does not affect how we write code - the reference is there purely for performance reasons, exactly how it is used today.
The issue about param address is already discussed.

A note about coroutines. This paper does not explore this space, but suggests, it is good idea to have different rules for deduction for coroutines. This is because references and coroutines do not match well. It looks like capture by copy to be much better option, however this is a separate discussion and for now coroutines should not support double parenths syntax. We simply don’t have enough experience with coroutines to be sure of the right defaults. Coroutines are significantly enough different, then either lambda or functions, and require a separate evaluation. Extending the current proposal can be done on later date.

The above scenario handles “observation” functions only. If the user wants to modify the original argument passed (or want to ensure it has its address passed to the function), then using both & or && are proposed to serve these purposes:

auto& incr((&src, delta)) { return src += delta; } //< `src` is of type auto&, `delta` is of type `const auto(&)`

[]((&&a)){ return some_func(std::forward<decltype(a)>(a)); } //< `a` is of type auto&&

By covering the 3 scenarios above (“observation”, “mutation”, “forwarding”) we solve all the issues listed above.

• Const is the default, matching the majority of cases and being the safest option.
• No hidden reference*. Normal references are introduced as usual (matching the capture syntax completely). Forwarding references are clearly visible, as always. At no point there is any potential confusion or uncertainty what the code does!
• No hidden mutability, yet easy to introduce when needed, with a well know, minimal syntax.

*The immutable reference is an implementation detail, an optimization, and is not semantically relevant.

In should be noted, so far auto&& as a default was ever only suggested in a very limited context - in a for-loop and lambdas (or lambda-like, single expression functions). Current proposal is not limited to those type of uses alone and anticipates typeless params potentially in normal functions as well. This changes the requirements a bit, as being able to express all common parameter usages (“observation”, “reference”, “forwarding”) is of much greater value. This is, while the niche use case of for-loop or lambda can be handled by one “good enough” type, a more universal support of deduced params require greater flexibility and expressiveness.
For example, consider helper functions, local to a cpp file, or a private function in class. In these scenarios it is quite possible, the user might not use concepts to define such functions and opt for the “quick-and-dirty” approach as the functions are not really part of an API and the extra effort to “do it right” might not be worth it. Or may be this is a changing code, in a prototyping stage - the user is unsure what the requirements are. In these scenarios it will be highly unlikely, the “forwarding reference” to be the right type (even less so for all arguments!), and is quite likely, the user will want some control over the parameters, at least in terms of mutability:

namespace {
  void assignPedalCrankFromRotorSpeed((&pedal, rotor)) { pedal = rotor / CHAIN_FACTOR; }
  ...
}

A local helper function

std::vector<int>  vi(10);
std::vector<bool> vb(10);
std::for_each(vi.begin(), vi.end(), [](auto& v) { v = 1; });    //< works
std::for_each(vb.begin(), vb.end(), [](auto& v) { v = true; }); //< fails: MUST be auto&&

std::vector<int>  vi(10);
std::vector<bool> vb(10);
std::for_each(vi.begin(), vi.end(), []((v)) { if(v == 1) ... ; });    //< works with current proposal as well
std::for_each(vb.begin(), vb.end(), []((v)) { if(v == true) ...; });  //< 

std::vector<int>  vi(10);
std::vector<bool> vb(10);
std::for_each(vi.begin(), vi.end(), []((v)) { if(v = 1) ... ; });    //< "just works"?
std::for_each(vb.begin(), vb.end(), []((v)) { if(v = true) ...; });  //< 

[]((a)){ return some_func(std::forward<decltype(a)>(a)); }

[]((&&a)){ return some_func(std::forward<decltype(a)>(a)); }

auto function((a, b, c)) {
  ...
  // 10 lines later
  something(a);
  ...
  // another 20 lines
  other_thing(std::forward<B>(b)); 
  ...
  // yet another 30 lines
  return do_it(std::forward<C>(c));
}

  ...
  // another 20 lines
  other_thing(std::forward<B>(b)); 
  ...
  // yet another 30 lines
  c.omn(b); //< ok?
  ...
  return do_it(std::forward<C>(c));
}

auto function((a, &&b, &&c)) { //< obviously not just observing
  ...
}

6.1 Alternative solution

The auto&& vs const auto& debade can change considerably if the core of the proposal (Part 1) is extended to allow specifying mutability for all arguments:

void function((a, b)const); //< All arguments are immutable

This shifts the optics about using auto&& as it becomes easier to gain immutability (as well as potential “maybe-reference” implementation).
Having such option does not contradict the const reference default as proposed, but makes many aspects of it redundant, like for example allowing & and && syntax:

void function((&a, &b)const); //< redundant with `const auto&` default

Some of the arguments pro explicit references still stand, but are greatly dampened, that is way this is more of an “Alternative solution”, not an “extension” - const ref default + parenth-const is not propsed.
Parenth-const creates some interesting possibilities, unrelated to abbreviated parameters, like allowing us to have all-const parameters in normal functions:

void function((std::string& s, std::vector<int>>& v, int i) const ); //< all arguments are immutable
//And/Or may be const in front
void function(const(std::string& s, std::vector<int>>& v, int i)); //< all arguments are immutable

As you can see, no abbreviated parameters in sight - we only take advantage of having to type just one const for all params. Of course, the value of this feature greatly depends on the number of parameters (and if we have a mix of const and non-const params), but is interesting nevertheless.

Arguably, the most interesting results are when this is applied to the theoretical for-range extension:

// `auto&&` is the default + parenth-const + range-for extension

for((e : list)const)  //< some verbosity for observation, but clear and safer

// equivalent to
for(const auto&& e : std::as_const(list)) //< and immutable container!

for((e : list)) //<  minimal-verbosity mutation and universal

// equivalent to
for(auto&& e : list)

As shown, this could solve the age-old problem where the list itself is not immutable, leading to undesired side-effects in some situations like when used with ref-counted containers.

Should be noted, when e is by default deduced to const auto& we can simply re-define the expression to have immutable container, if there is no reference on the element variable. In other words, we can get this feature (a const container) for free, because of the immutable default. The downside is that we lose minimal-verbosity mutation and we have to use && to be universal.

// `const auto&` is default _alone_ + range-for extension

for((e : list)) //< minimal-verbosity observation

// equivalent to
for(const auto& e : std::as_const(list)) //< and immutable container!

for((&&e : list)) //< to be universal, we need &&

// equivalent to
for(auto&& e : list)