Updated the proposal.
 + Improved wording about Part 2 not being "dependent" ot Part 1
 + Added section about why arguments-by-copy is not proposed
 + Extended the note regarding why coroutines are not covered for now
 + Added "Alternative solution" to the Appendix

On Sun, Jun 20, 2021 at 2:02 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Jun 19, 2021 at 1:16 PM Михаил Найденов via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Thanks for the feedback.
> > I have updated the proposal and it is now complete. I am also attaching
> a pdf version for easier viewing.
> >
> > Thank You!
>
> Your proposal keeps saying things like this, which I can't really agree
> with:
>
> > the current proposal, at its core (Part 1), does not depend on any
> particular deduced type.
>
> Yes, it does.
>
> This is a proposal for making code shorter. To effectively evaluate
> it, to determine if its benefits outweigh its costs, you *must* know
> exactly what code it can be used with and what code it cannot. That
> will determine whether it's worth doing.
>
> And this means that Part 1 is *dependent* on Part 2. If Part 2 is bad,
> Part 1 is pointless.
>
> Indeed, I would argue that none of the options are good. Or at least,
> none of them are good enough to be worth the cost of the feature as
> presented.
>
> The lambda proposal was worth the cost precisely *because* it
> shortened the body of the function. In cases of needlessly verbose
> lambdas, that's where most of the verbosity is. The verbosity of the
> header is not unimportant, but it is less significant, compared to the
> cases where verbosity really gets in the way of readability.
>
> This proposal picks low-hanging fruit, but all it is really doing is
> getting rid of `auto` from function prototypes. Whichever mechanism of
> deduction you pick, there are going to be more verbose use cases that
> need other forms of deduction.
>
> It should also be noted that you frequently use examples where the
> brevity on offer is irrelevant. If the code is 10+ lines long, *who
> cares* how many characters it takes to write the header? There is no
> reason to use the syntax unless brevity matters.
>
> This is also important for functions with lots of parameters. The more
> parameters there are, the more your suggestion saves in typing. But
> the more parameters there are, the longer the function body will
> likely have to be. Having to use `auto` in a parameter list is a lot
> less meaningful in a 3 line function than in a 1 line function.
>
> This is one of the reasons the abbreviated lambda proposal was so
> specific: it only *really* makes sense for short functions.
>
> > However, forwarding specifically is excursively a library (and/or
> wrapper) feature. These scenarios are by definition less common then “the
> general usage” - a “library” is meant for code-reuse, and code-reuse is
> “write once, reuse many times”. This is, the day-to-day usage of a language
> is always more common then writing a library.
>
> I find this line of argument highly dubious. And confusing.
>
> You make a strange distinction between "library" or "the general
> usage". I don't buy that such a distinction is meaningful (or very
> well explained). A piece of code is a "library" to whatever code calls
> it. It is "reusable" by whatever calls it. And most code is eventually
> called by some other code.
>
> Everything is a "library" to someone.
>
> > Hidden reference
>
> This entire section is self-defeating, since most of its arguments can
> be directed against your preferred `const&` solution. That too is a
> hidden reference.
>
> The only difference is that you (theoretically) cannot modify the
> object through it. But your arguments about how surprising it is that
> a variable is a reference without seeing `&` or `&&` anywhere is just
> as valid as it would be for the `const&` case. Indeed, the compile
> error you get when modifying it would be even more confusing, as you
> see neither `&` nor `const`.
>
> C++ doesn't have hidden `const` either (except in the case of captured
> lambda values). But you don't seem to have a problem adding them.
>
> If your argument is that `const&` will still be weird but *safer*,
> then that should be your argument, not that the reference is somehow
> not hidden.
>
> > This paper argues, a const reference and/or const copy as the best
> options for the deduced type.
>
> Not really. It just argues that `auto&&` would be bad. It never makes
> the case for `auto const&` being good. Indeed, it never even considers
> `auto`, which has the advantage of working exactly like everyone would
> expect.
>
> > allow optimizers to use copy instead for improved performance.
>
> You say this as though compilers were somehow prevented from doing
> precisely that. The two examples you provide are inline calls the
> compiler can easily see won't leak anywhere. So it can do basically
> whatever it wants.
>
> > This paper does not explore this space, but suggests, it is good idea to
> have different rules for deduction for coroutines. [...] for now coroutines
> should not support double parenths syntax
>
> This is unacceptable for two reasons:
>
> 1. A "coroutine" is a matter of the *implementation* of a function,
> not its *prototype*. As such, nobody can see that a function is a
> coroutine without looking at its implementation. You cannot
> effectively change the meaning of a function prototype based on stuff
> found arbitrarily far from the function prototype (ie: one of the
> `co_` statements/expressions). And you definitely cannot ban the
> construct from a function declaration based on how it is later defined
> (which may be in a different translation unit).
>
> 2. A good sign of a bad language feature is when the feature needs to
> behave radically differently in cases that aren't ultimately that
> different from each other.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>