Date: Wed, 25 Aug 2021 17:24:06 -0400
On Wed, Aug 25, 2021 at 3:47 AM Valery Osheter via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> As for your proposal, I see that it requires more syntax changes, and as a result, it seems to me that there is less chance of being approved.
That really should not be the focus of your proposal. The syntax you
use to create it is less important than the *utility* of what you're
creating. And resistance is going to be based more on whether it's
legitimately useful in the form you're proposing it, questions about
implementation difficulty, and looking at how complete the proposal
is.
For example, one *really* important question that you don't bring up
is this: what happens if you have one TU that has this
forward-declaration for members, and one TU that defines the type, but
the second TU never sees that forward-declaration? That's rather
important, since you say that if the eventual definition doesn't match
up with the forward declaration with all of its members, then it
should error out.
But that can't really happen *after* the compiler is done with the
type. The standard way to handle this is to say that it's a violation
of the ODR and therefore is il-formed, no diagnostic required (NDR).
That's acceptable currently because the standard way people declare
classes is to have a single file that provides the full definition of
that class. Two different users of a class simply include the same
header; they're not having to each type the class definition
themselves.
This becomes a lot less viable when you have multiple files that each
may have partial definitions, and the actual definition needs to match
up with them. From a practical perspective, NDR is *really* bad here.
It's way too easy to accidentally violate ODR with these things (a
simple typo can do it), and it would be exceedingly helpful if ODR
violations were diagnosable. Indeed, I might go so far as to say that
if it's possible to have these partial declarations and *not* diagnose
when they fail to match the definition, then we probably shouldn't do
it.
<std-proposals_at_[hidden]> wrote:
>
> As for your proposal, I see that it requires more syntax changes, and as a result, it seems to me that there is less chance of being approved.
That really should not be the focus of your proposal. The syntax you
use to create it is less important than the *utility* of what you're
creating. And resistance is going to be based more on whether it's
legitimately useful in the form you're proposing it, questions about
implementation difficulty, and looking at how complete the proposal
is.
For example, one *really* important question that you don't bring up
is this: what happens if you have one TU that has this
forward-declaration for members, and one TU that defines the type, but
the second TU never sees that forward-declaration? That's rather
important, since you say that if the eventual definition doesn't match
up with the forward declaration with all of its members, then it
should error out.
But that can't really happen *after* the compiler is done with the
type. The standard way to handle this is to say that it's a violation
of the ODR and therefore is il-formed, no diagnostic required (NDR).
That's acceptable currently because the standard way people declare
classes is to have a single file that provides the full definition of
that class. Two different users of a class simply include the same
header; they're not having to each type the class definition
themselves.
This becomes a lot less viable when you have multiple files that each
may have partial definitions, and the actual definition needs to match
up with them. From a practical perspective, NDR is *really* bad here.
It's way too easy to accidentally violate ODR with these things (a
simple typo can do it), and it would be exceedingly helpful if ODR
violations were diagnosable. Indeed, I might go so far as to say that
if it's possible to have these partial declarations and *not* diagnose
when they fail to match the definition, then we probably shouldn't do
it.
Received on 2021-08-25 16:24:20