Thanks. The actual path to take will depend on the actual paper to come.
Right now, what we have is a request for a «feature» in the list compiled
by P2966, and until there is an actual paper written on that one I don't
know what form the actual, formal request will take. I appreciate your
guidance, and I'm sure the paper authors will too (it might save time in
the end! :) )

Le mar. 19 sept. 2023 à 09:31, Jonathan Wakely <cxx_at_[hidden]> a écrit :

>
>
> On Tue, 19 Sept 2023 at 14:28, Patrice Roy <patricer_at_[hidden]> wrote:
>
>> Thanks Jonathan.
>>
>> The suggestion was to strike the note. Maybe that's not the way to go,
>> and just clarifying the text to avoid confusion would be better. I think
>> the fact that it's QoI is known, and the hope is to make that request known
>> to vendors in hope for an adjustment where needed.
>>
>
> Removing a note is not the right way to ask vendors to do things :-)
>
> If there's a bug where dynamic_cast is used unconditionally when
> __cpp_rtti is not defined, that's just a bug, and should be reported to the
> vendor. It's not a WG21 issue.
>
> Vendors that intend to support some kind of -fno-rtti mode should make
> non-standard changes to their std::lib implementation to work with that
> -fno-rtti mode. But that's entirely an issue for the vendors.
>
>
>
>>
>> For this (and other) paths suggested by this paper, I will involve the
>> original contributors in the individual papers to come, and we'll try to
>> make sure they get to express their intent clearly. If some issues are
>> found to be non-issues after further examination and discussion, they will
>> be identified as such in further revisions of P2966.
>>
>> Cheers!
>>
>> Le mar. 19 sept. 2023 à 09:09, Jonathan Wakely via SG14 <
>> sg14_at_[hidden]> a écrit :
>>
>>> Under “No RTTI” guarantees it says:
>>>
>>> Pursued. Many SG14 companies compile with
>>> RTTI turned off but might still want to use
>>> PMR allocators; however, some
>>> implementations use dynamic_cast in their
>>> PMR types. Offering PMR with a “no-RTTI”
>>> guarantee, or at least a compile-time
>>> checkable guarantee would be desirable.
>>> Consider eliminating note [mem.res.private-
>>> note-1]
>>>
>>>
>>> This is completely QoI. The standard doesn't require dynamic_cast there,
>>> and the note is talking about derived memory resources, possibly in the
>>> user's own code. It's just suggesting an optional optimization, which isn't
>>> needed at all, and can be made conditional on RTTI being enabled.
>>>
>>> If your implementation uses dynamic_cast unconditionally, complain to
>>> your vendor. They should do it conditionally, based on the __cpp_rtti
>>> feature test macro. That will work perfectly well with -fno-rtti or the
>>> equivalent.
>>>
>>> In any case, the only use of dynamic_cast I can find in any
>>> implementation of PMR is in GCC's experimental::resource_adaptor which
>>> already uses __cpp_rtti (and isn't in the standard yet, just a TS). Maybe
>>> the request should be considered for that type, as proposed for C++26 by
>>> P1083, but even there, I consider it completely QoI.
>>>
>>>
>>>
>>> _______________________________________________
>>> SG14 mailing list
>>> SG14_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>>
>>