Date: Mon, 25 Sep 2023 00:26:57 -0400
On Sun, Sep 24, 2023 at 10:38 PM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> You also want to use "new" and that's a library feature. You may want to use
>> dynamic_cast and, even that's similarly a library feature. Heck, sometimes
>> multiplications or divisions are runtime library features too.
>
>
> operator new, delete, etc... can be used without a header.
>
> Several years ago, I wanted to try something like TLSF with a few ideas of my own, which required writing malloc, free, etc... operator new is just a malloc wrapper. I'll add that it was worth the effort.
>
> I'll just say the thread might as well be closed for now, since its either venom or just walls of text about the obvious.
>
> My $0.75 (adjusted for inflation):
>
> Headers: bad
> Syntax: fun and elegant
> Syntax that needs a header: what?
>
> I actually brought up this issue and many others (elsewhere) before the proposal was final, and was met with the same tidal wave of venom. IIRC, the committee has never taken issue with ABI breakage,
That's categorically untrue. The committee has always taken great care
to avoid ABI breakage, and any proposal suggesting something that
would require such a breakage generally needs to be well-justified.
Note that "ABI breakage" in this case means like what happened with
`basic_string` when they forbid copy-on-write implementations in
C++11. Users who don't recompile their code against the new version of
the library cannot pass such types effectively into code compiled
against the old version of the library.
> and even in my personal projects I really do not care about that kind of thing. Re-building everything is already implied from one release of the standard to the next,
I'm glad you're in a situation where you can do that. Other people
aren't in such a situation, so when you say things like:
> so any point made on the basis of ABI breakage is moot, IMO.
That shows little more than that your opinion is extremely narrow. C++
is bigger than yourself.
> It seems presenting ideas here without first providing a toy implementation never gets any traction. "If you can't hack it into Clang, then nobody cares."
An implementation is not going to solve the underlying problems of
your idea. It isn't being rejected because we don't think it's
*possible* to implement. It's being rejected because we don't think
it's worthwhile, and the arguments you've made in defense of it are
either personal opinion/value statements ("Headers: bad") or are just
not well-founded.
> I'll have to come back to these things later.
<std-proposals_at_[hidden]> wrote:
>>
>> You also want to use "new" and that's a library feature. You may want to use
>> dynamic_cast and, even that's similarly a library feature. Heck, sometimes
>> multiplications or divisions are runtime library features too.
>
>
> operator new, delete, etc... can be used without a header.
>
> Several years ago, I wanted to try something like TLSF with a few ideas of my own, which required writing malloc, free, etc... operator new is just a malloc wrapper. I'll add that it was worth the effort.
>
> I'll just say the thread might as well be closed for now, since its either venom or just walls of text about the obvious.
>
> My $0.75 (adjusted for inflation):
>
> Headers: bad
> Syntax: fun and elegant
> Syntax that needs a header: what?
>
> I actually brought up this issue and many others (elsewhere) before the proposal was final, and was met with the same tidal wave of venom. IIRC, the committee has never taken issue with ABI breakage,
That's categorically untrue. The committee has always taken great care
to avoid ABI breakage, and any proposal suggesting something that
would require such a breakage generally needs to be well-justified.
Note that "ABI breakage" in this case means like what happened with
`basic_string` when they forbid copy-on-write implementations in
C++11. Users who don't recompile their code against the new version of
the library cannot pass such types effectively into code compiled
against the old version of the library.
> and even in my personal projects I really do not care about that kind of thing. Re-building everything is already implied from one release of the standard to the next,
I'm glad you're in a situation where you can do that. Other people
aren't in such a situation, so when you say things like:
> so any point made on the basis of ABI breakage is moot, IMO.
That shows little more than that your opinion is extremely narrow. C++
is bigger than yourself.
> It seems presenting ideas here without first providing a toy implementation never gets any traction. "If you can't hack it into Clang, then nobody cares."
An implementation is not going to solve the underlying problems of
your idea. It isn't being rejected because we don't think it's
*possible* to implement. It's being rejected because we don't think
it's worthwhile, and the arguments you've made in defense of it are
either personal opinion/value statements ("Headers: bad") or are just
not well-founded.
> I'll have to come back to these things later.
Received on 2023-09-25 04:27:10