Date: Tue, 4 Mar 2025 10:10:34 -0500
[[unsequenced]] might be good for const member functions. What is the name
of the attribute for non const member functions where it is a hybrid
between the [[unsequence]] and [[reproducible]]? Grossly speaking, the
this/self argument is [[reproducible]] and all the other arguments are
[[unsequence]].
If "pure is more relaxed than [[reproducible]]" and "const is more strict
than [[unsequenced]]", then is there still a need for [[pure]] and
[[const]] since they are different? Personally, I wouldn't mind having even
more strictness where possible.
In C. enforcement is not required but encouraged. If this is proposed for
C++, can we go ahead and make enforcement required. There are code
quality/understandability and safety benefits that arguably go beyond just
the optimization benefits.
On Tue, Mar 4, 2025 at 9:07 AM Pavel Vazharov via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Tue, Mar 4, 2025 at 4:03 PM Tymi via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Generally I wanted [[pure]] to be a combination of both [[unsequenced]]
>> and [[reproducible]].
>>
> As Jan Schultke has pointed out in his SO answer, [[unsequenced]] implies
> [[reproducible]].
>
>>
>> On Tue, 4 Mar 2025, 11:20 Tymi, <tymi.cpp_at_[hidden]> wrote:
>>
>>> I somehow didn't see your reply until now.
>>>
>>> Yes, you may call other pure functions from a pure function. I think it
>>> also might be okay to call constexpr/consteval functions as well.
>>>
>>>
>>> No, you may not call a function that could have side effects from a pure
>>> function. That could be ill-formed, no diagnostics required.
>>>
>>> Function parameters could be changed if it was passed by value, and of
>>> course, you don't call any unpure functions.
>>> Example:
>>> [[pure]] std::string AddX(std::string str)
>>> {
>>> str.append("X");
>>> return str;
>>> }
>>>
>>> Is fine.
>>>
>>> Yes, the compiler might assume that the function produces the same
>>> effect for the same arguments. It is up to the implementation, but
>>> generally you could make a lookup table or just call the function one and
>>> store its result.
>>>
>>> Tymi.
>>>
>>> On Tue, 4 Mar 2025, 08:07 Tymi, <tymi.cpp_at_[hidden]> wrote:
>>>
>>>> Some functions have no side effects, and while they can be often
>>>> optimised, the compiler is not aware of that.
>>>> Consider this example:
>>>> ```cpp
>>>> template <std::arithmetic T> constexpr T(const T a, const T b) { return
>>>> a + b; }
>>>> ```
>>>> That function could be declared as pure, or in other words, produces no
>>>> side effects.
>>>>
>>>> I think this is a great way to optimise frequent calls, such as a pure
>>>> function's result can be cached for the same arguments provided.
>>>>
>>>> Diagnostics: if a pure function has side effects, the compiler shall
>>>> issue a warning and calling that function is undefined.
>>>>
>>>> pure member function shall be declared as const, otherwise, the program
>>>> is ill-formed.
>>>>
>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
of the attribute for non const member functions where it is a hybrid
between the [[unsequence]] and [[reproducible]]? Grossly speaking, the
this/self argument is [[reproducible]] and all the other arguments are
[[unsequence]].
If "pure is more relaxed than [[reproducible]]" and "const is more strict
than [[unsequenced]]", then is there still a need for [[pure]] and
[[const]] since they are different? Personally, I wouldn't mind having even
more strictness where possible.
In C. enforcement is not required but encouraged. If this is proposed for
C++, can we go ahead and make enforcement required. There are code
quality/understandability and safety benefits that arguably go beyond just
the optimization benefits.
On Tue, Mar 4, 2025 at 9:07 AM Pavel Vazharov via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Tue, Mar 4, 2025 at 4:03 PM Tymi via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Generally I wanted [[pure]] to be a combination of both [[unsequenced]]
>> and [[reproducible]].
>>
> As Jan Schultke has pointed out in his SO answer, [[unsequenced]] implies
> [[reproducible]].
>
>>
>> On Tue, 4 Mar 2025, 11:20 Tymi, <tymi.cpp_at_[hidden]> wrote:
>>
>>> I somehow didn't see your reply until now.
>>>
>>> Yes, you may call other pure functions from a pure function. I think it
>>> also might be okay to call constexpr/consteval functions as well.
>>>
>>>
>>> No, you may not call a function that could have side effects from a pure
>>> function. That could be ill-formed, no diagnostics required.
>>>
>>> Function parameters could be changed if it was passed by value, and of
>>> course, you don't call any unpure functions.
>>> Example:
>>> [[pure]] std::string AddX(std::string str)
>>> {
>>> str.append("X");
>>> return str;
>>> }
>>>
>>> Is fine.
>>>
>>> Yes, the compiler might assume that the function produces the same
>>> effect for the same arguments. It is up to the implementation, but
>>> generally you could make a lookup table or just call the function one and
>>> store its result.
>>>
>>> Tymi.
>>>
>>> On Tue, 4 Mar 2025, 08:07 Tymi, <tymi.cpp_at_[hidden]> wrote:
>>>
>>>> Some functions have no side effects, and while they can be often
>>>> optimised, the compiler is not aware of that.
>>>> Consider this example:
>>>> ```cpp
>>>> template <std::arithmetic T> constexpr T(const T a, const T b) { return
>>>> a + b; }
>>>> ```
>>>> That function could be declared as pure, or in other words, produces no
>>>> side effects.
>>>>
>>>> I think this is a great way to optimise frequent calls, such as a pure
>>>> function's result can be cached for the same arguments provided.
>>>>
>>>> Diagnostics: if a pure function has side effects, the compiler shall
>>>> issue a warning and calling that function is undefined.
>>>>
>>>> pure member function shall be declared as const, otherwise, the program
>>>> is ill-formed.
>>>>
>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-03-04 15:10:48