Date: Mon, 2 Sep 2019 12:02:20 +0100
> >> If you presented a modified C compiler with reasonably designed
> built-in
> >> string object to the current C committee, I think you'd have a
> very high
> >> chance of success. Everybody recognises that strings need doing
> right,
> >> and a native built-in object is widely seen as the correct approach.
>
> I would say C is a non issue - we could, arguably just not care, and C++
> has enough to deal with a sized string type ( even without changing
> existing literals, strlen is _for all intent and purposes_ constexpr in
> all implementations)
I spoke only of the technical considerations, but there are many more
favourable *political* considerations if going via WG14 for a decent
native string object/view:
1. C needs it more than C++. A lot more. And C is small, so strings
"look bigger" relative to the whole.
2. C gets a lot more flak from the vulnerability guys, and a sizeable
chunk of the regular attendees come from vulnerability-related roles. So
unlike in WG21, a majority of WG14 thinks this stuff very important and
urgent.
3. You get the entire committee in a single room. To say that improves
speed of turnaround would be putting it mildly. You can get a very large
amount of very high quality feedback in a single presentation. You also
get much more collaboration, and counter proposal papers. They're
basically very helpful because they have the free time to be so, in a
way WG21 is not.
4. Whatever WG14 does usually gets pulled into WG21. It's a perfectly
valid alternative track for WG21 standardisation.
> The real problem is system apis (both posix and win32 and all existing C
> code) - null termination in C++ exist for compatibility with that and it
> seems unlikely that we would manage to convince win32 or posix people
> to add (pointer size) functions everywhere - it's a lot of functions
POSIX folk would just *love* to replace null terminated strings.
But everyone over at the Austin Working Group insist that C needs
formally agreed standards support for an alternative first, because this
would be a big breaking change, and they'd like to do it exactly once ever.
This is very doable. Somebody just needs to champion it through.
Niall
> built-in
> >> string object to the current C committee, I think you'd have a
> very high
> >> chance of success. Everybody recognises that strings need doing
> right,
> >> and a native built-in object is widely seen as the correct approach.
>
> I would say C is a non issue - we could, arguably just not care, and C++
> has enough to deal with a sized string type ( even without changing
> existing literals, strlen is _for all intent and purposes_ constexpr in
> all implementations)
I spoke only of the technical considerations, but there are many more
favourable *political* considerations if going via WG14 for a decent
native string object/view:
1. C needs it more than C++. A lot more. And C is small, so strings
"look bigger" relative to the whole.
2. C gets a lot more flak from the vulnerability guys, and a sizeable
chunk of the regular attendees come from vulnerability-related roles. So
unlike in WG21, a majority of WG14 thinks this stuff very important and
urgent.
3. You get the entire committee in a single room. To say that improves
speed of turnaround would be putting it mildly. You can get a very large
amount of very high quality feedback in a single presentation. You also
get much more collaboration, and counter proposal papers. They're
basically very helpful because they have the free time to be so, in a
way WG21 is not.
4. Whatever WG14 does usually gets pulled into WG21. It's a perfectly
valid alternative track for WG21 standardisation.
> The real problem is system apis (both posix and win32 and all existing C
> code) - null termination in C++ exist for compatibility with that and it
> seems unlikely that we would manage to convince win32 or posix people
> to add (pointer size) functions everywhere - it's a lot of functions
POSIX folk would just *love* to replace null terminated strings.
But everyone over at the Austin Working Group insist that C needs
formally agreed standards support for an alternative first, because this
would be a big breaking change, and they'd like to do it exactly once ever.
This is very doable. Somebody just needs to champion it through.
Niall
Received on 2019-09-02 13:02:22