Let me introduce this small thing I have in mind for some time.

The direction of modern programming emphasize mostly short and =20

single-purpose functions. Most of them are predicates and we can't =20

completely avoid writting forwarding functions. With const_expr comming =20

into standard, there will be a lot more of them.



Over time, I started formatting such functions like this:



   int func () { return *simple equation here*; };



or, when reaching often demanded imaginary 80-column limit, like this:



   int func ()

      { return *simple equation here*; };



The reasons for this formatting is to have more of code on the screen, an=
d =20

to have the code tabular for better orientation in packs of similar =20

functions. But actually because heavy use of qualifiers and C++-style =20

casts, this formatting exceeds the "row length" as well.





So the idea is, when we already have the function-try-blocks, why couldn'=
t =20

we be able to write just:



   int func ()

      return *simple equation here*;



At least 4 characters saved ;) The function-try-blocks were lattest, but =
=20

are probably not last, thing I discovered in C++. I can see (but I may be=
 =20

wrong) that they were introduced merely because of contructor initializer=
 =20

lists, but when the foundation is already in there why not to build on in=
?



I am really interesting in what do you think about this.

Is there a problem with described syntactic simplification that I don't =20

see?





Advantages:

+ No existing code get broken. I don't have very wide experiences with =20

various compilers but none I work with accept such code today.

+ Less "noise" characters and shorter rows allows more transparent code t=
o =20

be written

+ Will probably need not more than two short paragraphs of normative =20

wording



Subjective:

* A little prettier syntax for predicates and forwarding functions

* Could walk hand in hand with const_expr



Disadvantages:

- Not at all suitable for long expressions

- More programming for compiler vendors



--=20

Jan Ringo=B9, Tringi@MX-3.cz

http://Tringi.MX-3.cz

http://www.ringos.cz


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]