Date: Mon, 06 Nov 2023 16:08:55 -0600
On Mon, Nov 6, 2023, at 03:56, Jonathan Wakely via Std-Proposals wrote:
> On Sun, 5 Nov 2023, 13:48 Yexuan Xiao, <bizwen_at_[hidden]> wrote:
>
>> It is possible to vote on whether to mark a feature as discouraged.
>>
>
> Is that a good use of anybody's time though?
>
> Projects that are willing and able to move to new features like std::print
> will do so without being pressured into it. Projects that aren't able to
> move (for now, or ever) would just have developers annoyed by warnings that
> they can't do anything about.
That depends on how it works in the real world. I think we all agree new is something that should be marked as discouraged if this is adopted - there are better things for 99% of the cases, but that last 1% still exists where new is the correct thing (custom containers and placement new) However in reality most of us have multi-million line code bases of extending over decades. There is some C++98 code that has been rarely touched in the last 15 years, and so it just isn't worth the bother of updating it even though we all agree it should be done. What we want with discouraged is to quickly note all the existing places where new is used as grandfathered, that way when someone writes new code we catch where they use something discouraged and review the exception to see if it should be granted. Meanwhile we have a list of things that track in quality metrics if we care - in 50 years our grand children can happily remove the last thing from that list.
Note that I said note above, not mark. Marking in code triggers a code review and a lot of process around the right people reviewing each change. The important point I'm trying to bring out is something like discouraged or deprecated (which we already have but suffers the same problems) is that the processes around making it useful are more important than the syntax or ability. Tell me how I can use this new thing in my existing code without getting overwhelmed and I'm interested. Lacking that you are only useful for new projects, but they probably aren't going to use discouraged constructs much anyway, at least for the first 10 years until something better enters the standard and now they regret a lot of code (that couldn't have been written any other way at the time)
I have not proposed a solution. This is a hard problem, I would love for someone to propose something that works in the real world, but I do not know if a solution even is possible. So far though there are people who intuitively understand the problem who can't quite put it into words (or haven't tried?), and people who see a potential solution that works for hello world and don't realize why it isn't useful for large problems.
I'm in favor of the idea behind discouraged, but the details need to be worked out. The hard details are probably beyond the scope of the C++ standard, but without proof that wherever the scope of the details are will (not just can) implement their part the whole thing fails.
> On Sun, 5 Nov 2023, 13:48 Yexuan Xiao, <bizwen_at_[hidden]> wrote:
>
>> It is possible to vote on whether to mark a feature as discouraged.
>>
>
> Is that a good use of anybody's time though?
>
> Projects that are willing and able to move to new features like std::print
> will do so without being pressured into it. Projects that aren't able to
> move (for now, or ever) would just have developers annoyed by warnings that
> they can't do anything about.
That depends on how it works in the real world. I think we all agree new is something that should be marked as discouraged if this is adopted - there are better things for 99% of the cases, but that last 1% still exists where new is the correct thing (custom containers and placement new) However in reality most of us have multi-million line code bases of extending over decades. There is some C++98 code that has been rarely touched in the last 15 years, and so it just isn't worth the bother of updating it even though we all agree it should be done. What we want with discouraged is to quickly note all the existing places where new is used as grandfathered, that way when someone writes new code we catch where they use something discouraged and review the exception to see if it should be granted. Meanwhile we have a list of things that track in quality metrics if we care - in 50 years our grand children can happily remove the last thing from that list.
Note that I said note above, not mark. Marking in code triggers a code review and a lot of process around the right people reviewing each change. The important point I'm trying to bring out is something like discouraged or deprecated (which we already have but suffers the same problems) is that the processes around making it useful are more important than the syntax or ability. Tell me how I can use this new thing in my existing code without getting overwhelmed and I'm interested. Lacking that you are only useful for new projects, but they probably aren't going to use discouraged constructs much anyway, at least for the first 10 years until something better enters the standard and now they regret a lot of code (that couldn't have been written any other way at the time)
I have not proposed a solution. This is a hard problem, I would love for someone to propose something that works in the real world, but I do not know if a solution even is possible. So far though there are people who intuitively understand the problem who can't quite put it into words (or haven't tried?), and people who see a potential solution that works for hello world and don't realize why it isn't useful for large problems.
I'm in favor of the idea behind discouraged, but the details need to be worked out. The hard details are probably beyond the scope of the C++ standard, but without proof that wherever the scope of the details are will (not just can) implement their part the whole thing fails.
Received on 2023-11-06 22:09:36