RE: [boost] PP: BOOST_PP_IS_SEQ wanted

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-14 15:01:32

Paul Mensonides wrote:
> >> #define BOOST_PP_IS_SEQ BOOST_PP_IS_UNARY
> >>
> >> BOOST_PP_IS_SEQ( (a)(b)(c) ) // 1
> >> BOOST_PP_IS_SEQ( xyz )       // 0
> >> BOOST_PP_IS_SEQ( ++ )        // 0
> >>
> >> The second one with fail on Borland (and maybe IBM and Sun also),
> >> but otherwise it should work fine.
> >
> > Oh, great, can we have it under that name, then?
> 
> It is not an interface macro.  You can use it (e.g. 
> BOOST_PP_IS_UNARY), and it will remain, but I do not want to make 
> interfaces public that don't work properly on all major vendors.  

Why? I understand that, as the library author, you would much prefer 
all the facilities work properly on all the compilers (I, for 
instance, wish that was true for MPL as well), but _not including_ a
generally useful and wanted by real-world users functionality into 
the library because a couple of vendors have broken compilers is 
exactly the strategy I wouldn't expect any boost library to take.

> (I assume that you are trying to deal with an "end-of-seq" 
> indicator.  

No, I want to distinguish if a parameter passed to a macro is a
"plain" data or a sequence of "advanced" arguments.

> FYI, nil sequences are directly supported in the 
> "strict" pp-lib if using C99 facilities.)

If "strict" PP library makes it in our production environment, 
it's going to be more or less distant future. The need that generated 
my request for IS_SEQ is much more real.

> 
> The same is true for the identifier comparison.  You can use that
> implementation, but I don't want fragment the interface of the CVS 
> pp-lib.  If people want more heavy-duty facilities, they can use the
> "strict" version, which doesn't play around like the CVS version.

Well, I guess that's up to you, but if that's how it is going to end
up, it would definitely discourage me as a user to provide feedback 
and suggestions about the library we use to solve our day-to-day 
problems, and would push toward taking the current PP library 
"in-house".

Aleksey