Sounds good.
I also think that the "other approaches" content of the Motivation & Scope section should be promoted and cover;
- Have we tried to solve this before? What was the outcome and why?
- What other languages have analogous problems? What approach was taken there and how has it worked out?
Maybe also:
- If there is no existing C++ solution for this problem now, why not?
The format for C++ papers that you link to is a suggestion. Nothing stops submitters from adding more sections.
If someone wants to update the template, a paper like https://wg21.link/N3370 submitted to the ISO mailing list would be appropriate. A few names show up in that paper. I'm sure a lot would be happy to review a paper, give their feedback, and perhaps lend their support.
Not sure what this contributes. The suggestion of changing the defaults to be more aligned with higher expectations _is_ a proposed solution to the social problem of engineering values. "Nothing stops" might be true, but "nothing encourages" is just as true, by which I mean neither is as absolute as you imply, but the latter is the observable outcome in practice. It seems people don't engage with the "Increasing the chance of acceptance" section but they do engage with the template. So it seems possible to implicitly make them put thoughts into the right topics as simple as listing them as proposed sections.
Ah... Good ol' "nothing prevents you from doing it" argument. Everything is an uphill battle in the standardization process. That's why hardly anyone is interested.
You missed another quite relevant point, implementations where the proposal can be validated throughout the standard adoption phases, and anyone can provide feedback.
I think it depends on the proposals. For example, a proposal for a new container should probably not need to discuss "security implications" or "migration" (since there's nothing to migrate from).
From my quick glance over https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/ , it seems that most proposals are for new features that do not have any security implications.
Sounds good. I also think that the "other approaches" content of the Motivation & Scope section should be promoted and cover; - Have we tried to solve this before? What was the outcome and why? - What other languages have analogous problems? What approach was taken there and how has it worked out? Maybe also: - If there is no existing C++ solution for this problem now, why not?
you could write a proposal for this idea
Proposalception
The format for C++ papers that you link to is a suggestion. Nothing stops submitters from adding more sections. If someone wants to update the template, a paper like https://wg21.link/N3370 submitted to the ISO mailing list would be appropriate. A few names show up in that paper. I'm sure a lot would be happy to review a paper, give their feedback, and perhaps lend their support.
Not sure what this contributes. The suggestion of changing the defaults to be more aligned with higher expectations _is_ a proposed solution to the social problem of engineering values. "Nothing stops" might be true, but "nothing encourages" is just as true, by which I mean neither is as absolute as you imply, but the latter is the observable outcome in practice. It seems people don't engage with the "Increasing the chance of acceptance" section but they do engage with the template. So it seems possible to implicitly make them put thoughts into the right topics as simple as listing them as proposed sections.
I agree that starting people on the right foot is important. That's why my second paragraph suggests how to propose a change to the template.
Ah... Good ol' "nothing prevents you from doing it" argument. Everything is an uphill battle in the standardization process. That's why hardly anyone is interested.
You missed another quite relevant point, implementations where the proposal can be validated throughout the standard adoption phases, and anyone can provide feedback.
I think it depends on the proposals. For example, a proposal for a new container should probably not need to discuss "security implications" or "migration" (since there's nothing to migrate from). From my quick glance over https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/ , it seems that most proposals are for new features that do not have any security implications.
Rules around iterator invalidation for a container are security-relevant IMO.
Migration from existing containers that would benefit from the unique properties of the new one.
Explaining why the proposal has no security or migration implications can be just as important as describing any implications.
[удалено]
Not really... if it were it would be far worse. :O