Date: Sun, 3 Sep 2023 19:29:41 -0400
They have an inherent inclination to be critical of freestanding environments and encounter issues with C++ in a broader context.
Whenever someone raises concerns about exceptions, input/output operations, and so forth, there are individuals who vehemently oppose them.
I am currently attempting to compile C++ into Lua, but when I express my apprehensions, people immediately criticize me with remarks like, "Exceptions come at zero cost; why aren't you using them? You're incompetent." They make these comments without even attempting to understand the underlying problem. In reality, implementing C++ exceptions in Lua is not feasible, and even if it were, the performance overhead would be overwhelming.
When will we see innovations like "Herbceptions"? When will a genuine alternative to iostreams emerge? When can we replace std::locale with something else?
Why should we introduce new features before addressing existing issues in C++? Introducing new features prematurely will only result in further failures, similar to past additions like the GC interface, locale, regex, charconv, std::format, and std::filesystem.
What about discussing the overuse of std::unique_ptr? Is it really necessary to use std::unique_ptr<FILE, std::function<decltype(fclose)>> instead of simply creating a class?
I recently submitted a defect report, so why are there so many individuals who respond with unwarranted hostility?
And regarding allocators, they shouldn't even be a concern in freestanding environments.
Sent from Mail for Windows
From: std-proposals-request_at_[hidden]
Sent: Sunday, September 3, 2023 15:23
To: std-proposals_at_[hidden]
Subject: [External Email] Std-Proposals Digest, Vol 54, Issue 23
Send Std-Proposals mailing list submissions to
std-proposals_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
std-proposals-request_at_[hidden]
You can reach the person managing the list at
std-proposals-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Std-Proposals Digest, Vol 54, Issue 17 (Jason McKesson)
2. Re: Copy-construct, move-construct, and PR-construct
(Frederick Virchanza Gotham)
3. Re: Std-Proposals Digest, Vol 54, Issue 18 (Thiago Macieira)
4. Re: Std-Proposals Digest, Vol 54, Issue 17 (Thiago Macieira)
5. Re: Copy-construct, move-construct, and PR-construct
(Jason McKesson)
6. Re: Std-Proposals Digest, Vol 54, Issue 18 (Thiago Macieira)
7. Re: Copy-construct, move-construct, and PR-construct
(Frederick Virchanza Gotham)
----------------------------------------------------------------------
Message: 1
Date: Sun, 3 Sep 2023 10:39:34 -0400
From: Jason McKesson <jmckesson_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 17
Message-ID:
<CANLtd3VyDqbT6dXaNGsmE5qzrXotZT1pGUymWpsZ_cAcJ7y-Xw_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Sun, Sep 3, 2023 at 4:39?AM Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On Sun, 3 Sept 2023, 09:35 trtaab trtaab, <tvfvof_at_[hidden]> wrote:
>> Oh yeah. Their work LOL.
>>
>> Working on 7 years for nothing but a completely utter historical mistake like std::format, charconv instead of finding a solution to fix iostream? Std::addressof a C++11 feature only made freestanding after C++23?
>>
>> Exceptions being a completely joke even before I was born?
>>
>>
>> What are the work WG21 is doing?
>>
>>
>>
>> I think I have very right to attack and insult politicians in WG21.
>
>
> You've been acting like this for years and unsurprisingly it's got you nowhere. Why don't you just write your own language and compiler?
>
> Or get therapy to help with your inability to behave reasonably.
The sad part about all this is that the OP treats the committee as if
it is inherently hostile to freestanding, while in reality, the
committee has been very receptive towards expanding required
freestanding functionality.
Indeed, the primary impediment of freestanding stuff like this is
having the ability to get fine-grained requirements. That is,
freestanding was defined by headers in pre-C++23 in an all-or-nothing
kind of way; either everything in a header was a freestanding
requirement or nothing was. C++20 didn't require constexpr allocator
support to freestanding implementations because it *couldn't*, as this
would require everything else in the allocator header to be
freestanding requirements too. Ben Craig put forth a number of
proposals that were all based on adding fine-grained freestanding
requirements.
And to my knowledge, nobody reacted with any pushback on the idea
itself. Or if they did, it certainly didn't derail any of them.
Basically, all of the hostility is coming from one direction.
------------------------------
Message: 2
Date: Sun, 3 Sep 2023 16:06:15 +0100
From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
To: std-proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Copy-construct, move-construct, and
PR-construct
Message-ID:
<CALtZhhOGW+SStuZDdMPiV6NWY6Enn5586qvvDi4ER9qHXYZqsg_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Wed, Aug 23, 2023 at 4:10?PM Ville Voutilainen wrote:
>
> I wonder what happened to the third strategy, which is to pass as the
> argument of existing emplace an object
> that will perform the function invocation in its conversion operator
> to the optional's element type, which then
> allows doing this without any library or language changes, and has
> field experience as a solution to this problem.
This works fine so long as the type in question does not have a
constructor that accepts any type.
Arthur discusses this limitation here:
https://quuxplusone.github.io/blog/2018/05/17/super-elider-round-2/
I've been thinking though . . . what if we were to have a new overload
for placement new that accepts 'std::new_in_place' as the argument to
the constructor, something like:
namespace std {
template<typename T>
struct new_in_place {
virtual operator T(void) = 0;
};
}
Ando so then we would derive a class from it something like:
struct Monkey : std::new_in_place<std::mutex> {
operator std::mutex(void) override
{
// our code in here returns a mutex
}
};
And so then we would do:
std::optional<mutex> om;
om.emplace( Monkey() );
The implementation of 'std::optional' would then contain the following code:
::new(address) mutex( arg ); // 'arg' here is an R-value ref
that inherits from 'std::new_in_place'
The compiler would observe the decltype of the single argument to the
class's constructor and recognise it as inheriting from
'std::new_in_place', at which point the compiler would prevent any
class that derives from 'std::new_in_place' from becoming a template
parameter to a constructor, and so instead the compiler will invoke
the "conversion to T" operator.
Would something along these lines work? The idea I'm sharing here
would _not_ require an alteration to the implementation of
std::optional.
Basically I'm proposing some new compiler magic that disallows
'std::new_in_place' (or any dervied class) from being used as a
template parameter.
------------------------------
Message: 3
Date: Sun, 03 Sep 2023 11:39:57 -0700
From: Thiago Macieira <thiago_at_[hidden]>
To: trtaab trtaab via Std-Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 18
Message-ID: <1896873.eGJsNajkDb_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
[Off mailing list answer]
On Saturday, 2 September 2023 18:25:08 PDT you wrote:
> People like you are freaking stupid. I am talking about constexpr context
> you douch.
>
> C++ is a bad language because of people like you who cannot even read
> English.
You do realise that, however valid your argument was, you just lost all
credibility by sending this answer, right? Maybe Jason misunderstood you
(maybe he replied before his first coffee of the day), but that gives you no
right to insult him.
Attack the argument all you want and make your points heard, so long as you're
taking feedback into consideration. NEVER EVER attack the person making the
argument.
Just think about this.
You do not need to reply to me.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DCAI Cloud Engineering
------------------------------
Message: 4
Date: Sun, 03 Sep 2023 11:50:37 -0700
From: Thiago Macieira <thiago_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 17
Message-ID: <2665483.KRxA6XjA2N_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
On Sunday, 3 September 2023 07:39:34 PDT Jason McKesson via Std-Proposals
wrote:
> Indeed, the primary impediment of freestanding stuff like this is
> having the ability to get fine-grained requirements. That is,
> freestanding was defined by headers in pre-C++23 in an all-or-nothing
> kind of way; either everything in a header was a freestanding
> requirement or nothing was. C++20 didn't require constexpr allocator
> support to freestanding implementations because it *couldn't*, as this
> would require everything else in the allocator header to be
> freestanding requirements too. Ben Craig put forth a number of
> proposals that were all based on adding fine-grained freestanding
> requirements.
>
> And to my knowledge, nobody reacted with any pushback on the idea
> itself. Or if they did, it certainly didn't derail any of them.
Unfortunately, absence of evidence is not evidence of absence.
Which is the problem here: the community interested in freestanding C++ is
tiny, usually unable to provide said feedback in a timely fashion. This means
advancement is left to the rest of the committee whose priorities differ
substantially and thus freestanding C++ advances very, very slowly. The
solution for this is quite clear: get together and make proposals, feedback
and possibly even proofs of concept.
That their interests also often diverge is another problem (see what happened
to Contracts).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DCAI Cloud Engineering
------------------------------
Message: 5
Date: Sun, 3 Sep 2023 14:51:55 -0400
From: Jason McKesson <jmckesson_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Copy-construct, move-construct, and
PR-construct
Message-ID:
<CANLtd3UTiecABWwKx_kW6n-DyqK+MHehxvDeOOg2HJEtwY8NDQ_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Sun, Sep 3, 2023 at 11:06?AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wed, Aug 23, 2023 at 4:10?PM Ville Voutilainen wrote:
> >
> > I wonder what happened to the third strategy, which is to pass as the
> > argument of existing emplace an object
> > that will perform the function invocation in its conversion operator
> > to the optional's element type, which then
> > allows doing this without any library or language changes, and has
> > field experience as a solution to this problem.
>
>
> This works fine so long as the type in question does not have a
> constructor that accepts any type.
> Arthur discusses this limitation here:
>
> https://quuxplusone.github.io/blog/2018/05/17/super-elider-round-2/
>
> I've been thinking though . . . what if we were to have a new overload
> for placement new that accepts 'std::new_in_place' as the argument to
> the constructor
When coming up with solutions, it's often good to lay out the problem
as explicitly as possible.
So, the circumstance we have involves 3 things:
1. A type `T`.
2. An emplace-based API that is going to construct a `T` with an
expression of the form `new(addr) T(std::forward<Args>(args)...)` from
a list of arguments of deduced types via perfect forward.
3. An expression which evaluates to a prvalue of type `T`.
And what we want is to make it so that the result of #3 is used in the
expression in #2 in a way that doesn't provoke a copy/move operation
from #1.
The semi-idiomatic solution is to wrap #3 in a functor which has a
conversion operator to `T` that, when invoked, will result in
evaluating #3. Through the rules of prvalues, no copying or moving
will be invoked.
The issue is that, when looking for user-defined conversions,
conversions in a constructor are given priority over conversion
operators in the given object type. As such, if `T` has a conversion
constructor that is a template which can be used with the wrapper
type, that will break the idiom. The constructor will be preferred
over the conversion operator.
So, your suggestion is to invent a facility that changes this prioritization.
OK, so.. why did you shove it into some random standard library type?
That looks like a giant hack that only makes sense for this specific
use case.
A more reasonable idea is to tag either the class as a whole or the
conversion operator with an actual language feature. That feature
would mean that, when the type is used as the source of an implicit
conversion (or the specific operator is possible in such a
conversion), constructors on the destination type are ignored. I'm not
sure if an existing keyword can be used here (`explicit` is absolutely
the wrong one), but there would need to be some property applied to
the type/operator itself. It could even in theory be a contextual
keyword like `final`.
------------------------------
Message: 6
Date: Sun, 03 Sep 2023 11:52:27 -0700
From: Thiago Macieira <thiago_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 18
Message-ID: <10934038.5MRjnR8RnV_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
On Sunday, 3 September 2023 11:39:57 PDT Thiago Macieira via Std-Proposals
wrote:
> [Off mailing list answer]
Oops, turns out it wasn't (the mailing list software mangled the sender,
defeating the "reply to author" feature). But I didn't write anything I
wouldn't say in public anyway.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DCAI Cloud Engineering
------------------------------
Message: 7
Date: Sun, 3 Sep 2023 20:22:53 +0100
From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Copy-construct, move-construct, and
PR-construct
Message-ID:
<CALtZhhMBeiMx87D+QoMuFx5YpKAa304ueKVYxAzRfgUUV+jqiA_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Sun, Sep 3, 2023 at 7:52?PM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> A more reasonable idea is to tag either the class as a whole or the
> conversion operator with an actual language feature. That feature
> would mean that, when the type is used as the source of an implicit
> conversion (or the specific operator is possible in such a
> conversion), constructors on the destination type are ignored. I'm not
> sure if an existing keyword can be used here (`explicit` is absolutely
> the wrong one), but there would need to be some property applied to
> the type/operator itself. It could even in theory be a contextual
> keyword like `final`.
Something like:
struct Monkey final {
operator mutex(void) priority
{
// our code in here returns a mutex
}
};
If a conversion operator is marked as 'priority' then in the following
circumstance:
::new(p) T( Monkey() );
Even if T has a template constructor that could accept an object of
type 'Monkey', the compiler instead will search inside the class
'Monkey' for a conversion operator marked 'priority', and if found,
will invoke it. Two rules for marking a conversion operator as
'priority':
(Rule 1) A class definition shall contain at most one conversion
operator marked as 'priority'.
(Rule 2) Only a class marked as 'final' may contain a conversion
operator marked as 'priority'.
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 54, Issue 23
*********************************************
Received on 2023-09-03 23:32:13