Advertisement
leomaster

GCC Suggestion

Dec 14th, 2014
269
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.25 KB | None | 0 0
  1. TLDR: [GCC Suggestion] allow bracketless functions (for single statement body)
  2.  
  3.  
  4. Dear kind people of the gcc development team,
  5.  
  6. My name is Leonidas and i am currently studying Computer Science in the Department of Informatics, University of Athens, Greece
  7.  
  8. I am writing this letter to you because i would like to make a suggestion about a "new" feature/functionality of the gcc.
  9.  
  10. Basicly the description is the following:
  11. Any function with a code body of only one statement should be able to be recognized properly by gcc without the need of braces { } similar to the way the rest of the statements work (if, while, for etc...)
  12.  
  13. Allow me to illustrate with the following example.
  14. Consider this simple C program which compiles and runs perfectly:
  15.  
  16. uppercase(c) {
  17. return c-'a'+'A';
  18. }
  19.  
  20. main() {
  21. putchar(uppercase('a'));
  22. }
  23.  
  24. I am suggesting that gcc should be able to compile correctly this program if it was written like this:
  25.  
  26. uppercase(c)
  27. return c-'a'+'A';
  28.  
  29. main()
  30. putchar(uppercase('a'));
  31.  
  32.  
  33. I am aware that the same effect can be implemented via the use of preprocessor macros, however that solution is far from elegant since the goal of this feature is to allow the possibility of more compact code. (less is more)
  34.  
  35. I am also aware that bracketless coding style is frowned upon by a considerable part of the community, however it is important by a compiler to provide every option and let the programmer decide the one he prefers. (freedom of choice)
  36.  
  37. I am asking you to seriously consider this suggestion even tho it's not predicted by the grammar; i believe gcc already compiles more stuff than what the grammar allows anyway. (gcc leads the way)
  38.  
  39. I also strongly believe it's the logical step for this feature to become part of the next ISO C as it renders even more coherence for the brace operators (or lack of them for that matter). (feels so obvious)
  40.  
  41. In the case of the existence of a serious reason as of which this feature is impossible to be developed as part of the standard build (e.g it interferes with function prototyping), i am asking of you to please make your best efforts to at least include it via the use of an argument flag.
  42.  
  43.  
  44.  
  45. Regardless of your decision i am patiently awaiting for your response.
  46.  
  47. Thank you in advance
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement