Date: Sun, 3 Sep 2023 01:19:15 +0000
You are wrong.
::operator new and ::operator delete are NOT constexpr.
https://github.com/microsoft/STL/issues/1532
https://github.com/microsoft/STL/issues/4002
There is no way to allocate memory in CONSTEVAL context.
It is a standard bug.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>
Sent: Saturday, September 2, 2023 15:35
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Std-Proposals Digest, Vol 54, Issue 16
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: Real World Programming, private = public (Andrey Semashev)
2. Re: Real World Programming, private = public (Jason McKesson)
3. PR: std::allocator<T>::allocate is not freestanding
(trtaab trtaab)
4. Re: PR: std::allocator<T>::allocate is not freestanding
(trtaab trtaab)
----------------------------------------------------------------------
Message: 1
Date: Sat, 2 Sep 2023 19:38:18 +0300
From: Andrey Semashev <andrey.semashev_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID: <41295a7c-9b88-1081-df3e-f172a89d0e3b_at_[hidden]>
Content-Type: text/plain; charset=UTF-8
On 9/2/23 19:22, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
>>
>> You keep talking about syntax as though that was the problem. It isn't.
>>
>> You are asking to be able to trivially bypass access controls. That's
>> the feature you want.
>>
>> That is not a thing the language should provide. It renders access
>> controls essentially meaningless. The syntax by which it is provided
>> is irrelevant when the *functionalty itself* is a bad idea.
>
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.
>
> You also seem to have no concept of harm reduction. C++ programmers
> around the world today are typing out "#define private public".
This last claim needs some proof. In my >20 years of programming, I
never had to do this, and I have a really hard time believing this is
such a widely used practice that it requires to be part of the language.
------------------------------
Message: 2
Date: Sat, 2 Sep 2023 12:41:45 -0400
From: Jason McKesson <jmckesson_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID:
<CANLtd3UjDoExAc0C2Cixvo2ji8X7=r9PS6FZg8JX-HwwbVKTHw_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Sat, Sep 2, 2023 at 12:22?PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
> >
> > You keep talking about syntax as though that was the problem. It isn't.
> >
> > You are asking to be able to trivially bypass access controls. That's
> > the feature you want.
> >
> > That is not a thing the language should provide. It renders access
> > controls essentially meaningless. The syntax by which it is provided
> > is irrelevant when the *functionalty itself* is a bad idea.
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.
If you lock a door but put a sign up saying that the key is under the
mat, the door is *functionally* unlocked. Protections are only as good
as the means to circumvent them.
Features you add to the language will be used against whatever purpose
you added them to the language for. If you give everyone a trivially
accessible key to an object's privates, people *will use them*
whenever access controls make their lives even slightly more
difficult.
> You also seem to have no concept of harm reduction.
I guess that depends on how you define "harm".
When a programmer declares something private, what they're saying is
that it should not be accessed by code outside of their control. Why?
One reason is that it is *subject to change*. By declaring something
private, they're saying that they reserve the right to change it, but
in a way that is compatible with the class's public interface.
By accessing something you aren't supposed to, you are denying that
programmer the right to change it. If they change it, now everyone who
accessed those privates gets broken. Which restricts their ability to
change it. It forces people to use the Pimpl idiom just to prevent
people from inhibiting their ability to later modify their own code.
I consider that to be "harm". Therefore, your feature suggestion does
not reduce "harm"; it exacerbates it.
> C++ programmers around the world today are typing out "#define private public".
Programmers doing bad things is not a good reason to add a language
feature. Also, that's a good argument for further adoption of modules,
since it renders this linguistically impossible.
Lastly, [citation needed]. Like, I'm sure that *some* programmers have
done that. But what makes you think that this is a tool that is in
even mildly significant use/demand?
------------------------------
Message: 3
Date: Sat, 2 Sep 2023 19:22:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: [std-proposals] PR: std::allocator<T>::allocate is not
freestanding
Message-ID:
<DM4PR02MB90694B8CE1AA7F9DCF16FBF3C7EBA_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
This is std::addressof situation 2.0
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 4
Date: Sat, 2 Sep 2023 19:35:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
freestanding
Message-ID:
<DM4PR02MB90697361512FDBD3941CDC3CC7EBA_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
BTW:
::std::allocator_traits<T>::allocate with a hint has the same issues too.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: trtaab trtaab<mailto:tvfvof_at_[hidden]>
Sent: Saturday, September 2, 2023 15:22
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: PR: std::allocator<T>::allocate is not freestanding
Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
This is std::addressof situation 2.0
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
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 16
*********************************************
::operator new and ::operator delete are NOT constexpr.
https://github.com/microsoft/STL/issues/1532
https://github.com/microsoft/STL/issues/4002
There is no way to allocate memory in CONSTEVAL context.
It is a standard bug.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>
Sent: Saturday, September 2, 2023 15:35
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Std-Proposals Digest, Vol 54, Issue 16
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: Real World Programming, private = public (Andrey Semashev)
2. Re: Real World Programming, private = public (Jason McKesson)
3. PR: std::allocator<T>::allocate is not freestanding
(trtaab trtaab)
4. Re: PR: std::allocator<T>::allocate is not freestanding
(trtaab trtaab)
----------------------------------------------------------------------
Message: 1
Date: Sat, 2 Sep 2023 19:38:18 +0300
From: Andrey Semashev <andrey.semashev_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID: <41295a7c-9b88-1081-df3e-f172a89d0e3b_at_[hidden]>
Content-Type: text/plain; charset=UTF-8
On 9/2/23 19:22, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
>>
>> You keep talking about syntax as though that was the problem. It isn't.
>>
>> You are asking to be able to trivially bypass access controls. That's
>> the feature you want.
>>
>> That is not a thing the language should provide. It renders access
>> controls essentially meaningless. The syntax by which it is provided
>> is irrelevant when the *functionalty itself* is a bad idea.
>
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.
>
> You also seem to have no concept of harm reduction. C++ programmers
> around the world today are typing out "#define private public".
This last claim needs some proof. In my >20 years of programming, I
never had to do this, and I have a really hard time believing this is
such a widely used practice that it requires to be part of the language.
------------------------------
Message: 2
Date: Sat, 2 Sep 2023 12:41:45 -0400
From: Jason McKesson <jmckesson_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID:
<CANLtd3UjDoExAc0C2Cixvo2ji8X7=r9PS6FZg8JX-HwwbVKTHw_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"
On Sat, Sep 2, 2023 at 12:22?PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
> >
> > You keep talking about syntax as though that was the problem. It isn't.
> >
> > You are asking to be able to trivially bypass access controls. That's
> > the feature you want.
> >
> > That is not a thing the language should provide. It renders access
> > controls essentially meaningless. The syntax by which it is provided
> > is irrelevant when the *functionalty itself* is a bad idea.
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.
If you lock a door but put a sign up saying that the key is under the
mat, the door is *functionally* unlocked. Protections are only as good
as the means to circumvent them.
Features you add to the language will be used against whatever purpose
you added them to the language for. If you give everyone a trivially
accessible key to an object's privates, people *will use them*
whenever access controls make their lives even slightly more
difficult.
> You also seem to have no concept of harm reduction.
I guess that depends on how you define "harm".
When a programmer declares something private, what they're saying is
that it should not be accessed by code outside of their control. Why?
One reason is that it is *subject to change*. By declaring something
private, they're saying that they reserve the right to change it, but
in a way that is compatible with the class's public interface.
By accessing something you aren't supposed to, you are denying that
programmer the right to change it. If they change it, now everyone who
accessed those privates gets broken. Which restricts their ability to
change it. It forces people to use the Pimpl idiom just to prevent
people from inhibiting their ability to later modify their own code.
I consider that to be "harm". Therefore, your feature suggestion does
not reduce "harm"; it exacerbates it.
> C++ programmers around the world today are typing out "#define private public".
Programmers doing bad things is not a good reason to add a language
feature. Also, that's a good argument for further adoption of modules,
since it renders this linguistically impossible.
Lastly, [citation needed]. Like, I'm sure that *some* programmers have
done that. But what makes you think that this is a tool that is in
even mildly significant use/demand?
------------------------------
Message: 3
Date: Sat, 2 Sep 2023 19:22:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: [std-proposals] PR: std::allocator<T>::allocate is not
freestanding
Message-ID:
<DM4PR02MB90694B8CE1AA7F9DCF16FBF3C7EBA_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
This is std::addressof situation 2.0
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 4
Date: Sat, 2 Sep 2023 19:35:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
freestanding
Message-ID:
<DM4PR02MB90697361512FDBD3941CDC3CC7EBA_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
BTW:
::std::allocator_traits<T>::allocate with a hint has the same issues too.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: trtaab trtaab<mailto:tvfvof_at_[hidden]>
Sent: Saturday, September 2, 2023 15:22
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: PR: std::allocator<T>::allocate is not freestanding
Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
This is std::addressof situation 2.0
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
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 16
*********************************************
Received on 2023-09-03 01:19:18