snake_case everything for robustness & consistency?

[helmesjo]

As per the issue policies, I'll post it here as an "open discussion" instead of an issue.

It's very nice to see the documentation starting to take shape, great work!

One thing I noticed though are some inconsistencies regarding snake_case & PascalCase, which reminded me of the last minute change to the predefined concepts naming convention in C++20. Could a preferred & recommended convention be of value (eg. how rust does it)? Personally, it is of tremendous value to reduce the mental processing when looking through external code, and maybe could now be a chance to "nudge" it in the right direction? Thinking ahead a bit, it could even be the case where (opt-in) auto-formatting comes bundled "as a thing" with cpp2.

It might be worth considering early on if just sticking to snake_case for everything in cpp2 could be a small, "why not" kind of improvement (including examples). It also seems like an effort worth while "to honor" cpp1 which has managed it thus far (AFAIK).
One example are the predefined contract groups: cpp2::Default, cpp2::Type, cpp2::Bounds, cpp2::Null, cpp2::Testing.

Since issues related to "always snake_case" are (always?) caused by deficiencies/ambiguity in the compilers and/or the C++ syntax (eg. auto my_type = my_type{};), it might actually be a of real value to stick with only snake_case so that these issues are caught early on & dealt with "properly" (whatever the solution might be). It might just be another good layer of automatic sanity-checking of the new syntax.

If anyone has examples where snake_case doesn't work great in the current cpp1 syntax, or where my arguments are flawed, it'd be interesting to see and verify if it'll be an issue in cpp2.

[SebastianTroy]

In my experience I've only seen snake case in legacy situations, it seems to me that pascal and/or camel case are preferred almost unanimously I'm any modern setting. I believe this is because capitalising a letter is much more fluid when typing than inserting underscores, and because capitalisation rules can differentiate between types and variables / functions. Despite the standard library itself being snake case, the vast majority of all C++ code I have seen has not been snake case. I believe this is fairly good evidence that forced snake case would be rejected/disliked by a lot of developers. If you're seriously pro snake case, could I suggest at least kebab case, as it doesn't require both hands to type the spacing character. (replaces underscore with dash) On 11 March 2024 18:50:03 Fred Helmesjö ***@***.***> wrote: As per the issue policies, I'll post it here as an "open discussion" instead of an issue. It's very nice to see the documentation starting to take shape, great work! One thing I noticed though are some inconsistencies regarding snake_case & PascalCase, which reminded me of the last minute change to the predefined concepts naming convention<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1754r0.pdf> in C++20. Could a preferred & recommended convention be of value (eg. how rust does it<https://rust-lang.github.io/api-guidelines/naming.html>)? Personally, it is of tremendous value to reduce the mental processing when looking through external code, and maybe could now be a chance to "nudge" it in the right direction? Thinking ahead a bit, it could even be the case where (opt-in) auto-formatting comes bundled "as a thing" with cpp2. It might be worth considering early on if just sticking to snake_case for everything in cpp2 could be a small, "why not" kind of improvement (including examples). It also seems like an effort worth while "to honor" cpp1 which has managed it thus far (AFAIK). One example are the predefined contract groups<https://hsutter.github.io/cppfront/cpp2/contracts/#contract-groups>: cpp2::Default, cpp2::Type, cpp2::Bounds, cpp2::Null, cpp2::Testing. Since issues related to "always snake_case" are (always?) caused by deficiencies/ambiguity in the compilers and/or the C++ syntax (eg. auto my_type = my_type{};<https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIAMwapK4AMngMmAByPgBGmMQgAKykAA6oCoRODB7evgFBaRmOAmER0SxxCcl2mA5ZQgRMxAQ5Pn6Btpj2xQwNTQSlUbHxSbaNza15HQrjA%2BFDFSOJAJS2qF7EyOwcM8ReDgDULACeAPoExymYJgDsVjcAIib%2BVhoAgibv4QRHTOEQy0%2BHzuQIOYIOTC8RCOZwuVwOzweMPOl2uIMez1ewIeHFWtE4iV4fg4WlIqE4bms1gOCnWm0wCLM/h4pAImlxqwA1iAzEF8RxJET2WTOLwFCAgmySbjSHBYEg0CwUnR4uRKIrlfQEgA3ZApFKnbVcACcpwMBEwM1OqgAHAA2Ph0C3EcUQGLCmLhJrHTgsz3MYjHADyMW0tSlLMVbEEQYYtB90tIWBiXmAbjEtHF3F4WBYhmA4kT%2BGI4bw2stwswqlqUO2LO%2BXWFtDwMWI3o8WGFBGIeBYvplVAMwAUADU8JgAO5Bq7Eln8QQiMTsKQyQSKFTqRO6Lj6fMoKmWfQt8WQVaoFI9cUAeiDZjJ5eIPawJ4BnW6WRcDHcnjaelC83KSo9EKTIBEmPwdxAnpBkAkYdxqOoBD6CYfzyeCulLJDZhg4YEng2ZwL0GZ%2BhwxY8NWWkNi2CQ8QJIVE3JDgDltO0jgUXUDiNY0ADpzUtH4IFwQgSEZZlll4KUtGWLkeT5ThBVIYlSUYsUJVZdlVjlRAUFQJUVTICgIA1fSQGALh/DvGhaGdV13UTf1vX7UgHMDEMwwcJyo0YAhY3jYVk1TdNaEzJzc3zQtSWLUtyyzUkqxrC0nIbflSWbVt2wwbZSW7Xt%2B1WQcmGHMdJ2nRgnPnYRRHEFcKvXNRhV0O8DCMfdLGsI8YhfM8LyyLNeFQB8nwrU830wvwIFcQid3/MpcOA9JQOyVCINSBboIAub0PfLD%2Bim0bEN6bCNrIoiCOW06SOOoCuAoulqJu/Q6MU4VGOY%2B0AFo7UkA5gGQZADnM7izAOQT8CIYhRJuiSNJk3lHoFejlNFWw1MkmUtIgBVdM1VVDOMrUUGasybS4IIrJsyg7NJFyEz9L1XNDcNPN06MfLjBNIswFM0wzLMWTCowIpzPASzqGLK2rZBaySwRG0TNK20DDssokns%2B2zfKh1HccpxncrZEXarpFqpR6q3AJdxa0w2sPNKurJHqBD6%2B94iG%2B2EJ6T9v1yFaZoWa7VqKLI9qgrJSIDj36jOn2iIwg7kLmWaTvw3bzpT5pw7g26qOXWiOEJZ6GM4N67U%2B77kCJgGbW4rhuI0EGhPByHxPU6VpNIbk4f5BSlP65HxUlDTZRgbT1gIFIoTVIzsf0yJWG2Fiy5%2Bv6Af8IHeEwMGSDwdA9Aqw3l2N2Q6s3UlGtICc2xSPL4YL3uRQ4IMoQnn5UCoEul9%2B/7AeBiAPD0rUokzAtzRu3TuckEaFyRhwVSg8255zMIjPuMDW5SVWA%2BDIzhJBAA%3D%3D>), it might actually be a of real value to stick with only snake_case so that these issues are caught early on & dealt with "properly" (whatever the solution might be). It might just be another good layer of automatic sanity-checking of the new syntax. If anyone has examples where snake_case doesn't work great in the current cpp1 syntax, or where my arguments are flawed, it'd be interesting to see and verify if it'll be an issue in cpp2. — Reply to this email directly, view it on GitHub<#1018>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQIAKG4RJ4UYBSITSO3YXX4FTAVCNFSM6AAAAABEQ3QJ4GVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGM2TSMBRG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[helmesjo]

it seems to me that pascal and/or camel case are preferred almost unanimously I'm any modern setting.

I'd guess the main drivers has been Java & C#. I would argue though that style more often than not comes from familiarity, not objective reasoning. That said, replacing space with something else (eg. _ or -) improves readability if one assumes the text I'm writing is easier to read ThanSomethingLikeThis followedByThis (since this is how all other text we come across is written). Anyways, this wasn't so much about which convention but rather sticking to one, avoiding a mix. For C++, my guess is that underscore will be less intrusive to the language (especially if we assume no mix).

I believe this is fairly good evidence that forced snake case would be rejected/disliked by a lot of developers.

I totally agree, so to clarify the auto-formatting idea: It'd have to be opt-in. My argument is rather that having a languages' convention be consistent between projects would be a big upside & if that likelihood could be improved I'm all for it.

[gregmarr]

If you're seriously pro snake case, could I suggest at least kebab case, as it doesn't require both hands to type the spacing character. (replaces underscore with dash)

Dashes are not allowed in identifiers.

[SebastianTroy]

Ah, I guess it could be non white spaced minus operator? Fair enough On 12 March 2024 17:18:28 gregmarr ***@***.***> wrote: If you're seriously pro snake case, could I suggest at least kebab case, as it doesn't require both hands to type the spacing character. (replaces underscore with dash) Dashes are not allowed in identifiers. — Reply to this email directly, view it on GitHub<#1018 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQKCVNSCU5YLZU2UKRLYX42GDAVCNFSM6AAAAABEQ3QJ4GVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONRSHE3DG>. You are receiving this because you commented.Message ID: ***@***.***>

[hsutter]

One example are the predefined contract groups: cpp2::Default, cpp2::Type, cpp2::Bounds, cpp2::Null, cpp2::Testing.

Yes, I think those are the only examples... and the reason for those is to avoid default.

1. I could just rename Default to default_.

2. Or I could add "default" to the list of names that get cpp2_ prefixes (but then Cpp1 code that used it would have to call cpp2_default.report_violation() for example).

Maybe 2 is best?

[zaucy]

I don't think the cpp2_ prefix is that bad. Maybe even dropping the namespace would be fine?

[helmesjo]

I agree, 2. sounds resonable.

[gregmarr]

Maybe unspecified instead of default?

[DyXel]

I voted "No". But I think I might have misunderstood the poll, if this is only for conventions within cppfront's code (so compiler work and the utils around it), then yeah, I agree sticking with a name convention and implementing the 2nd point Herb suggested in his post.

If this is also about projects which would adopt cppfront, then I would stick with the "No" as that to me seems out of scope for what cpp2 is trying to be (easily adoptable, which means being able to use your existing conventions in your project or existing ones).

[helmesjo]

I voted "No". But I think I might have misunderstood the poll, if this is only for conventions within cppfront's code (so compiler work and the utils around it), then yeah, I agree sticking with a name convention and implementing the 2nd point Herb suggested in his post.

Correct, this was only for convention within cpp2, so that there are as few "surprises" as possible for a coder when working with cpp2.

If this is also about projects which would adopt cppfront, then I would stick with the "No" as that to me seems out of scope for what cpp2 is trying to be (easily adoptable, which means being able to use your existing conventions in your project or existing ones).

Yep I reckon my phrasing was a bit ambiguous. What I meant was that since cppfront reads and understands all of the cpp2 syntax, it could be a great feature (opt-in) to say cppfront -format .... Not only would it increase the chance of cpp2 code being created looks & feels the same, it would also sanity-check things since hard-to-format syntax would be a "smell" (think c++ + clang-format/clang-tidy & their endless config values). Few required format configurations/customization-points & close-to-no special-cases would indicate a solid proof of sane syntax.

[hsutter]

OK, because I already didn't like having to capitalize those because of Default, I'll take this path and go to all lowercase consistently throughout, as Standard C++ already generally does. That has benefits such as that UserCodeIdentifiers are visibly different (if the user's code chooses to use such a different convention).

[hsutter]

Closed by f65c153

[hsutter]

Thanks!