On Mon, Oct 18, 2010 at 6:29 PM, Matt Calabrese <rivorus@gmail.com> wrote:
Sorry for the triple reply. Even though it's not a difficult change, I'm torn. My gripe with making it one macro is it implies extra surrounding parentheses and simply looks a bit more cluttered and confusing.
I'm jumping in at the middle here, so pardon my questions/interjection. I would like to say that the parentheses don't bother me, that's already the case with Boost.Concept_check's macro system, and is something that can be addressed by documentation and (lots) of examples.
That sounds like it's not a big deal, which it may not be, but it does at the very least make the original use-case more complicated.
I don't see it that way. You're addressing a problem that could very well still be addressed by the language designers -- this macro would only be useful in case the standard doesn't change. Now say the standard doesn't get changed to support what you're proposing (I really hope you'll write the N**** paper so that the C++ committee members can address your concern and the (now in hindsight) obvious mistake), the use case you intend to enable deserves enough attention. Additional expressive power in the form of an additional set of parentheses is hardly an issue IMO.
After all, the reason it was called "auto function" to begin with is because its original intent was to deduce the return type. If you separate the declaration from implementation, the return type isn't even deducible anymore, so it seems at least somewhat questionable to change the design to support such a feature. For instance
template< typename T > BOOST_AUTO_FUNCTION( foo( T arg ) ) ( ( if is_integral< T > ) ( return arg + 1 ))
as opposed to
template< typename T > BOOST_AUTO_FUNCTION( foo( T arg ) ) ( if is_integral< T >) ( return arg + 1 )
The first one, at least to me, seems more complicated and less resembles a function.
Well, I'd like to say that the first version makes more sense to me, because I know that the requirements and the body go together -- that is, the requirements might not even be there to begin with, so the extra parentheses won't be required IIUC.
It's true that "break" is one more thing to know, but making the entire thing one macro invocation makes the original use-case -- automatically deduced return types -- more complicated.
I could always just make a 2nd macro which puts everything into a single invocation without requiring "break" by just implementing it in terms of my current macro. Then I could expose them both and let users decide what they want.
Either way, it should be easy to implement the changed design on top of the current design by wrapping, but not the other way around, so I think I'll just continue on as I am now and figure things out later.
I'd like to encourage you to keep it to one macro and let the users learn the extra parentheses required. This is the case with Boost.Concept_check and I don't complain much about that -- although I'm also the guy who likes Common Lisp and Haskell, so I might be biased to either having more parentheses or none at all and not so much whatever is in between these extremes. :D -- Dean Michael Berris deanberris.com