David Abrahams <dave@boost-consulting.com> writes:
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
FWIW, one of the main reasons I brought this issue up was that I was hoping you'd convince me that the reasons to do it your way were important enough to outweigh the reasons to go the other way.
If you let people add a semicolon after the macro, how can you change the macro later in a way that doesn't tolerate a trailing semicolon? The expansion of the macro is an implementation detail; the interface shouldn't depend on a particular expansion.
Right?
I agree; that's the first argument I find truly compelling. All the other ones, including the arguments I started with, seem a bit weak by comparison.
Thank you.
I am still hesitating though, because the macros in question aren't really an abstraction: the library is designed to be usable without the macros (in case you don't like them or whatever), and the library documents exactly what they generate.
Having given this further thought, I don't think it matters that they're not an a very strong abstraction. It still might make sense to change the library in the future in a way that's compatible with the "normal" usage of the old macro. -- Dave Abrahams Boost Consulting www.boost-consulting.com