Date: Sun, 02 Feb 2025 11:02:27 -0800
On Sunday 2 February 2025 03:38:31 Pacific Standard Time Jonathan Wakely via
Std-Proposals wrote:
> > I understand this viewpoint; but in having accepted '.' (in a post '.'
> > derefercing pointer view) it is a consistent behavior to access a member
> > of
> > an object rather than 2 methods. Just because idomatic C++ doesn't get
> > the
> > same benefit of 'consistency' now that you mention these things, seems
> > unfair to keep others from having it... but then who besides me maintains
> > C
> > that is also C++ compilable? Do we/should we really even care about
> > compatibility?
>
> Yes, we do and we should.
Expanding a bit on that:
The C standards committee may decide it's beneficial to their language to add
that, under their own rules. But they should understand that C++ does not need
this and probably has a weak opposition to it (see below). Therefore, the C
committee should understand from their vendors who provide both C and C++
which ones would not accept as part of the language or as an extension,
because that limits the adoption in C in the first place.
In the C++ side, I would expect coding style rules to enforce use of -> even
with plain pointers, because refactoring does happen and dumb pointers become
smart. Therefore, this feature would have nearly zero benefit for C++ and might
be actively banned in many codebases.
This is why I think C++ has a weak opposition to it. But I also expect us to
just either adopt it into the language if C has it or rely on most compilers
having it as an extension.
Divergence from C wouldn't be the first time:
- Variable Length Arrays
- Flexible Array Members
- Designated Initialisers (for arrays and out-of-order)
- Anonymous Structs
I believe MSVC++ has FAMs and anonymous structs because the Win32 headers use
those extensively, but it does not have VLA and does not support the other
modes of designated initialisers in C++ mode.
Std-Proposals wrote:
> > I understand this viewpoint; but in having accepted '.' (in a post '.'
> > derefercing pointer view) it is a consistent behavior to access a member
> > of
> > an object rather than 2 methods. Just because idomatic C++ doesn't get
> > the
> > same benefit of 'consistency' now that you mention these things, seems
> > unfair to keep others from having it... but then who besides me maintains
> > C
> > that is also C++ compilable? Do we/should we really even care about
> > compatibility?
>
> Yes, we do and we should.
Expanding a bit on that:
The C standards committee may decide it's beneficial to their language to add
that, under their own rules. But they should understand that C++ does not need
this and probably has a weak opposition to it (see below). Therefore, the C
committee should understand from their vendors who provide both C and C++
which ones would not accept as part of the language or as an extension,
because that limits the adoption in C in the first place.
In the C++ side, I would expect coding style rules to enforce use of -> even
with plain pointers, because refactoring does happen and dumb pointers become
smart. Therefore, this feature would have nearly zero benefit for C++ and might
be actively banned in many codebases.
This is why I think C++ has a weak opposition to it. But I also expect us to
just either adopt it into the language if C has it or rely on most compilers
having it as an extension.
Divergence from C wouldn't be the first time:
- Variable Length Arrays
- Flexible Array Members
- Designated Initialisers (for arrays and out-of-order)
- Anonymous Structs
I believe MSVC++ has FAMs and anonymous structs because the Win32 headers use
those extensively, but it does not have VLA and does not support the other
modes of designated initialisers in C++ mode.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-02-02 19:02:32