Date: Sat, 19 Jun 2021 19:01:51 -0400
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_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.
Received on 2021-06-19 18:02:09