Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always put const at the beginning #19

Open
Chlumsky opened this issue Dec 3, 2021 · 1 comment
Open

Always put const at the beginning #19

Chlumsky opened this issue Dec 3, 2021 · 1 comment
Labels
code-generation Involves generation of parser / serializer code imperfection A mostly cosmetic issue tentative Not yet decided if this should be done

Comments

@Chlumsky
Copy link
Owner

Chlumsky commented Dec 3, 2021

To avoid errors, I have put the const keyword for references of uknown types to the safe spot after the type name. However, this is somewhat inconsistent and it is a general convention to have it at the beginning whenever possible. Since pointer and reference types are not supported and static array types do not use references (this part is resolved), I believe it would actually be safe to put const back at the beginning without changing anything else. It also needs to be updated in the standard library API's and the Readme file. Is it a good idea though? How about normalizing it the other way around (always putting const in this position)?

@Chlumsky Chlumsky added imperfection A mostly cosmetic issue tentative Not yet decided if this should be done code-generation Involves generation of parser / serializer code labels Dec 3, 2021
@Chlumsky
Copy link
Owner Author

Fixed for TypeName::constRefArgDeclaration in da46380, which is used for serializer function signatures. API templates remain unchanged for now, which I think is OK, as they don't have sufficient information about underlying type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-generation Involves generation of parser / serializer code imperfection A mostly cosmetic issue tentative Not yet decided if this should be done
Projects
None yet
Development

No branches or pull requests

1 participant