Date: Sat, 22 May 2021 19:26:14 +0000
Am Samstag, den 22.05.2021, 19:03 +0000 schrieb Ben Craig:
> > Deprecating volatile on return types seems like a good idea, but on parameters it has a valid
> > uses.
>
> Do you have a compelling example? What are the valid uses of volatile on a parameter?
The one already mentioned in the paper: longjmp / setjmp.
Martin
_______________________________
> From: Liaison <liaison-bounces_at_lists.isocpp.org> on behalf of Uecker, Martin via Liaison <
> liaison_at_[hidden]>
> Sent: Saturday, May 22, 2021 11:54 AM
> To: liaison_at_[hidden] <liaison_at_lists.isocpp.org>
> Cc: Uecker, Martin <Martin.Uecker_at_med.uni-goettingen.de>
> Subject: [EXTERNAL] Re: [wg14/wg21 liaison] n2743 Volatile C++ Compatibility
>
> Am Samstag, den 22.05.2021, 11:25 -0400 schrieb Aaron Ballman via Liaison:
> > On Sat, May 22, 2021 at 10:49 AM Philipp Klaus Krause via Liaison
> > <liaison_at_lists.isocpp.org> wrote:
> > > Am 22.05.21 um 16:08 schrieb Robert Seacord via Liaison:
> > > The remaining rationale apparently is just 'C++ removed the feature, so
> > > we should, too', which also seems a rather weak one to me.
> >
> > Some of the deprecations touch on interfaces that would plausibly show
> > up in headers shared between C and C++ (specifically, volatile on
> > return types and on parameter types), so those particular cases are of
> > importance for compatibility between C and C++.
>
> Deprecating volatile on return types seems like a good idea,
> but on parameters it has a valid uses. I find the suggestion
> that one can copy those into a new variable not very convincing.
> It would be another special exception. We should make the
> language simpler and not more complicated.
>
> There is also no reason to include qualifiers in prototypes,
> so these do not have to leak implementation details. One
> could consider deprecating all qualifiers on parameters in
> function declarations that are not part of a function
> definitions. This would make more sense to me.
>
> Martin
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!4Wpy2ms0Dg0L6TakcZUAUmPJq8sdqRJe5Z2bMCTZcTQJUhRXiulJI0I1U34n$
> Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0587.php__;!!FbZ0ZwI3Qg!4Wpy2ms0Dg0L6TakcZUAUmPJq8sdqRJe5Z2bMCTZcTQJUhRXiulJIyftQ8Zk$
> > Deprecating volatile on return types seems like a good idea, but on parameters it has a valid
> > uses.
>
> Do you have a compelling example? What are the valid uses of volatile on a parameter?
The one already mentioned in the paper: longjmp / setjmp.
Martin
_______________________________
> From: Liaison <liaison-bounces_at_lists.isocpp.org> on behalf of Uecker, Martin via Liaison <
> liaison_at_[hidden]>
> Sent: Saturday, May 22, 2021 11:54 AM
> To: liaison_at_[hidden] <liaison_at_lists.isocpp.org>
> Cc: Uecker, Martin <Martin.Uecker_at_med.uni-goettingen.de>
> Subject: [EXTERNAL] Re: [wg14/wg21 liaison] n2743 Volatile C++ Compatibility
>
> Am Samstag, den 22.05.2021, 11:25 -0400 schrieb Aaron Ballman via Liaison:
> > On Sat, May 22, 2021 at 10:49 AM Philipp Klaus Krause via Liaison
> > <liaison_at_lists.isocpp.org> wrote:
> > > Am 22.05.21 um 16:08 schrieb Robert Seacord via Liaison:
> > > The remaining rationale apparently is just 'C++ removed the feature, so
> > > we should, too', which also seems a rather weak one to me.
> >
> > Some of the deprecations touch on interfaces that would plausibly show
> > up in headers shared between C and C++ (specifically, volatile on
> > return types and on parameter types), so those particular cases are of
> > importance for compatibility between C and C++.
>
> Deprecating volatile on return types seems like a good idea,
> but on parameters it has a valid uses. I find the suggestion
> that one can copy those into a new variable not very convincing.
> It would be another special exception. We should make the
> language simpler and not more complicated.
>
> There is also no reason to include qualifiers in prototypes,
> so these do not have to leak implementation details. One
> could consider deprecating all qualifiers on parameters in
> function declarations that are not part of a function
> definitions. This would make more sense to me.
>
> Martin
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!4Wpy2ms0Dg0L6TakcZUAUmPJq8sdqRJe5Z2bMCTZcTQJUhRXiulJI0I1U34n$
> Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0587.php__;!!FbZ0ZwI3Qg!4Wpy2ms0Dg0L6TakcZUAUmPJq8sdqRJe5Z2bMCTZcTQJUhRXiulJIyftQ8Zk$
Received on 2021-05-22 14:26:24