"Stable" naming conventions (when and how)

[epagone]

In #336 there has been a discussion about naming conventions for that PR and (as sometimes happens) there was not a clear agreement. Of course, we need to be pragmatic and we shouldn't over agonise about such choices (especially considering that we are still in the experimental phase) but I believe that it is important to discuss and decide when we want to poll a wider sample of users and make a decision for the "stable" version of a stdlib subset.

More importantly, what platforms and criteria should we use to make a final decision? Obvious options could be the Discourse forum and the majority of votes for a specific naming convention, but I am not sure if it is the best choice. What do you think?

I feel that this is not a stdlib specific type of issue, it encompasses all fortran-lang projects, probably (see here just for an fpm example).

[awvwgk]

We had similar issues with naming for the to_upper and to_lower functions, the alternative and maybe even preferred choice seemed to be uppercase and lowercase, which happened to already be used in the same module for global parameters.

As far as I understood non of the naming choices are binding until the function enters the stable namespace, in practice a choice introduced in the experimental namespace will be harder to change due to inertia and might also be taken as reference in other discussions to argument for a specific naming. I remember seeing arguments referring to to_lower and to_upper in #336.

Polling the community in the discourse might be an idea, but should only be the last resort if we cannot agree on the issue or patch discussion. I would rather encourage the community to actively participate in the discussions on the issue tracker and patch review at the respective project.

[awvwgk]

The recent discussion heavy string patches might also be partly my fault, because I send a patch rather than starting an issue to discuss first.

This was maybe on purpose because the original general string thread #69 has become stale in a way (GitHub issues tend to “break down” after 50+ comments) and a lot of intermediary results that were somewhat agreed didn't really found a way into an actual code change. In an effort to revive the discussion and move the string project forward I'm trying to propose patches working along the previous discussion, it's certainly not perfect and I'm open for feedback on this.

[milancurcic]

The recent discussion heavy string patches might also be partly my fault, because I send a patch rather than starting an issue to discuss first.

I thought about this too and I think it's fine. Discussion can happen here or there. Discussion before making a PR can sometimes save some wasted effort, but often we just enjoy making a PR that it doesn't really matter. And discussing in the PR can have an advantage because you can see the code "in the flesh", and it can be easier to get a feel for an API when it's implemented.