RE: [boost] PP: BOOST_PP_IS_SEQ wanted

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-29 05:49:15

Sorry for the late reply.

Paul Mensonides wrote:
> >> However:  at a certain point, that level of 'hacking' becomes a
> >> maintenance nightmare, as does fracturing portability by
> >> enabling and disabling features on various compilers.
> >
> > I would say I don't see how saying "this feature doesn't works on
> > such and such compilers" leads to a maintenance nightmare. It's 
> > definitely less work for the maintainer, isn't it? Say, if 
> > portability wasn't one of the important goals of the MPL, I would 
> > _gladly_ give up some of the workarounds for a simple statement 
> > "this doesn't work on broken compilers such as ...". It would 
> > definitely make library's maintenance way easier.
> 
> No, but saying that "this feature is unstable on several 
> compilers" would. BOOST_PP_REPEAT + BOOST_PP_SEQ_ELEM is an example 
> of just how brittle things can be running under VC++.  (One way or 
> another, that is something that I _can_ make work properly, so I will 
> fix that when I can get to it.)  The maintenance problems start to 
> come up when library primitives are combined on buggy preprocessors.  
> The primary problem is _encapsulation_ and avoiding a *combinatorial*
> nightmare when these "next-level" primitives are used by user code.  
> It isn't just a question of whether or not feature X with work on
> preprocessor Y, it is a problem with whether feature X will work 
> with feature Y on preprocessor Z.

OK, I understand.

> > As for the above issue, pp-sequences themselves cannot contain that
> > kind of data, can they? For instance, I am pretty sure this one will
> > fail as well
> >
> >     BOOST_PP_SEQ_ELEM(0, (a, b, c)(a))
> >
> > although, strictly speaking, (a, b, c)(a) _is_ a sequence. Frankly, 
> > I don't think it's an important corner case either. For anyone more 
> > or less familiar with C++ preprocessor it's obvious that the above 
> > won't work, and why.
> 
> It isn't a corner case.  The long term final result of the sequence 
> mechanism is direct support for variadic sequences, as well as nil 
> sequences.  This functionality is already available in C99.  With 
> variadics, it is easy to manipulate arbitrary sized tuples.  However, 
> that isn't the common case.  The common case is something like this:
> 
> (a, b)(a, b)(a, b)
> 
> I.e. a binary sequence.  Variadics sequences support any size with 
> only one mechanism.  Likewise, I could have designed the sequence 
> mechanism to support nil sequences directly, and consequently make 
> using sequences more difficult, but I chose not to because that is 
> not what it will be eventually.  Besides, what you're doing is 
> overloading a macro based on the "type" of its operand. This reminds 
> me of the conversation we had a while back regarding generic 
> algorithms for different pp-data types.  The different types are 
> syntactically too similar to be differentiated in this way--even with
> variadics. Compiler problems aside, the name BOOST_PP_IS_SEQ implies 
> a sort of "type" detection, which I cannot do in general. With the 
> IS_UNARY detection process, what your doing is very low-level. It is 
> not a high-level facility that would qualify for a name like 
> BOOST_PP_IS_SEQ. Which is why I prefer the more low-level name
> BOOST_PP_IS_UNARY. If you *really* think I should, I'll promote those
> detection macros to interface macros, and see how stable I can make 
> the COMPARE mechanism, because I respect your opinion.  However: 
> These facilities are *use-at-your-own-risk*.

I still think that from the user's point of view, the semantics/
limitations of BOOST_PP_IS_SEQ aren't any worse than any other SEQ 
primitive, and that users that need this functionality would be happy 
to find it under an intuitive name. But I can relate myself to your 
position, so not doing it would be fine with me.

Thanks for the discussion,
Aleksey