Date: Wed, 25 Aug 2021 08:23:21 +0100
What about virtual functions? Do you want these to be declarable outside the class? I think those would have similar ABI issues.
Personally I like the "partial type definition" idea. If we want to protect against different orders in different TUs then maybe we could mandate to give each part a name, and each part should refer to the previous part, if there is any. The part that completes the type shouldn't have a name.
class C/part1 {
int i;
};
class C/part2 extends(part1) {
int j;
};
class C extends(part2) {
int k;
}; //completes the type
This is just a dummy syntax.
Cheers,
Lénárd
-------- Original Message --------
From: Valery Osheter via Std-Proposals <std-proposals_at_[hidden]>
Sent: August 25, 2021 5:28:41 AM GMT+01:00
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Valery Osheter <valery.o_at_[hidden]>, sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Partial type definition
I see that the discussion goes to the direction I did not expect.
So maybe the caption should be changed from "partial type definition" to
"declaration of methods outside of the class definition". This is my real
intent. I think it does not hurt ODR, because ODR requires only one
definition and allows several equvalent declarations. If the declarations
are not equal, the linker fails just like in case of plain function in C++.
I hope that this feature so simple and attractive, the compilers can do it
literally tomorrow.
On Tue, Aug 24, 2021, 23:08 Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Tue, 24 Aug 2021 at 23:05, Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> > I doubt it's viable to allow the real definition of X to omit the
> > things defined in the partial definition. A translation
> > unit that sees the real definition might not see the partial
> > definition, and then you have a serious ODR problem.
>
> ..which is not to say that this idea isn't riddled with different ODR
> problems to begin with, though. :)
>
Personally I like the "partial type definition" idea. If we want to protect against different orders in different TUs then maybe we could mandate to give each part a name, and each part should refer to the previous part, if there is any. The part that completes the type shouldn't have a name.
class C/part1 {
int i;
};
class C/part2 extends(part1) {
int j;
};
class C extends(part2) {
int k;
}; //completes the type
This is just a dummy syntax.
Cheers,
Lénárd
-------- Original Message --------
From: Valery Osheter via Std-Proposals <std-proposals_at_[hidden]>
Sent: August 25, 2021 5:28:41 AM GMT+01:00
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Valery Osheter <valery.o_at_[hidden]>, sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Partial type definition
I see that the discussion goes to the direction I did not expect.
So maybe the caption should be changed from "partial type definition" to
"declaration of methods outside of the class definition". This is my real
intent. I think it does not hurt ODR, because ODR requires only one
definition and allows several equvalent declarations. If the declarations
are not equal, the linker fails just like in case of plain function in C++.
I hope that this feature so simple and attractive, the compilers can do it
literally tomorrow.
On Tue, Aug 24, 2021, 23:08 Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Tue, 24 Aug 2021 at 23:05, Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> > I doubt it's viable to allow the real definition of X to omit the
> > things defined in the partial definition. A translation
> > unit that sees the real definition might not see the partial
> > definition, and then you have a serious ODR problem.
>
> ..which is not to say that this idea isn't riddled with different ODR
> problems to begin with, though. :)
>
Received on 2021-08-25 02:23:31