Re: [boost] Call for interest - BOOST_AUTO_FUNCTION

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-10-18 06:45:24

On Mon, Oct 18, 2010 at 6:29 PM, Matt Calabrese <rivorus_at_[hidden]> 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