Date: Sat, 30 Dec 2023 19:09:00 +0200
On Sat, 30 Dec 2023 at 18:27, Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Friday, 29 December 2023 18:30:33 -03 Andrew Tomazos via Std-Proposals
> wrote:
> > Please find attached a short 2-page proposal:
> >
> > D3077R0 Proposal of static_cast shorthand: <T>(x) DRAFT 1
> > https://isocpp.org/files/papers/D3077R0.pdf
>
> This is missing a strong motivation section. The fact that something is used a
> lot doesn't mean we need two ways to do the same thing.
>
> Please address in your paper one of the main advantages of the C++ keyword
> casts which static_cast does obey: that it's a very distinctive token and
> easily searchable in codebases. Address why you think that we can do away with
> this benefit. You obviously used this fact in searching the code base in your
> paper, so it has some benefit. Please provide an opinion on the benefit of your
> syntax versus the loss of the searchability.
>
> And please add a section explaining how this cannot be ambiguous for existing
> code already. In that section, please look into expressions involving the <
> and > operators, so we don't unintentionally create a problem like C++98 's
> need for a space in > >.
Or multiple times please don't, since this paper is a waste of
everybody's time, as static_cast is
non-terse by design, and we have better things to do.
<std-proposals_at_[hidden]> wrote:
>
> On Friday, 29 December 2023 18:30:33 -03 Andrew Tomazos via Std-Proposals
> wrote:
> > Please find attached a short 2-page proposal:
> >
> > D3077R0 Proposal of static_cast shorthand: <T>(x) DRAFT 1
> > https://isocpp.org/files/papers/D3077R0.pdf
>
> This is missing a strong motivation section. The fact that something is used a
> lot doesn't mean we need two ways to do the same thing.
>
> Please address in your paper one of the main advantages of the C++ keyword
> casts which static_cast does obey: that it's a very distinctive token and
> easily searchable in codebases. Address why you think that we can do away with
> this benefit. You obviously used this fact in searching the code base in your
> paper, so it has some benefit. Please provide an opinion on the benefit of your
> syntax versus the loss of the searchability.
>
> And please add a section explaining how this cannot be ambiguous for existing
> code already. In that section, please look into expressions involving the <
> and > operators, so we don't unintentionally create a problem like C++98 's
> need for a space in > >.
Or multiple times please don't, since this paper is a waste of
everybody's time, as static_cast is
non-terse by design, and we have better things to do.
Received on 2023-12-30 17:09:13