RE: [boost] Re: A couple of issues in submitting typelists to boo st

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-11-27 15:40:01

Emily Winch wrote:
> So, there are functions, which expose a return value called 
> "type", there are  objects which expose a "type" because 
> they can be used as functions, and there are objects which 
> are definitely not functions and should not expose a 
> return value.

Exactly. 

> People who write _normal_ functions manage to cope somehow 
> without naming their return value :) 

Yeah, I wondered how I do it too :). IMO "normal" functions can be
classified into the same two categories as well: ones which return value's
type is obvious from the name of the function (i.e. which are in the same
category as add_const<>; "person.name()" is one example, although may be a
controversial one :), and the ones for which you infer the information about
their return value's type _mainly_ from the function's signature or its
usage context (or from reading the docs :); for example, if it was possible
to write:

    std::pair<my_iterator,bool> res(map.insert(777));

as

    auto typename T res(map.insert(777));

when one would have no chances to guess what type "res" is, without looking
at std::map<>::insert signature, or reading the docs (supposing that it's
the first time she came across this function, of course :). 

So, the issue is pretty much the same in the "run-time world" as well, it's
only shaded a little bit by the language strong static type system that
forces you to write clues about function return type all over the place :).
Hmm, just realized that I haven't thought about dynamic-typed languages :). 

Anyway, I guess you are right in sense that it's mainly a matter of
familiarity with the library; after you've used 'find<seq, T>' for a while,
'find<>::type' would be as clear to you as 'find<>::iterator', and the
former is shorter :).

> So long as it is clearly documented that "type" means "return  
> value" and not "member variable named type", then I think the
> intention is not  confusing. (other people's MMV...)

Hmm.. may be the ability to write both 'begin<seq>::iterator' as well as
'begin<seq>::type' is indeed a misfeature, and we should stick to simple and
consistent "::type" everywhere.. what do you think?

> Also useful would be a convention for denoting the return 
> type of a runtime function, where that type depends on the 
> template parameters of the function, like this
> 
> struct X{
>   template<class T> struct get_return_type{
>     typedef typename long_calculation_with_T<T>::type type;
>   };
>   template<class T>
>   typename get_return_type<T>::type
>   operator()( /* whatever */ ){
>     /* runtime stuff */
>   }
> };

Yes, IMO handling both runtime and compile-time computations
simultaneously/in the same place makes a perfect sense, and often it's the
only way to do things effectively. In fact, chances are that I would write
the above as 

    template<class T>
    struct X {
      typedef typename calculation_with_T<T>::type type;
      type operator()( /* whatever */ ){
        /* runtime stuff */
      }
    };

FWIW, a while ago MPL had the following:

    template<typename SequenceTag>
    struct back_algorithm_traits
    {
        template<typename Sequence> struct algorithm
        {
            typedef /**/ type;
            static type& result(Sequence& seq) { return /**/; }
            static type const& result(Sequence const& seq) { return /**/; }
        };
    };

    template<typename Sequence>
    struct back
        : back_algorithm_traits< 
              typename mpl::sequence_traits<Sequence>::sequence_category
              >::template algorithm<Sequence>
    {
    };

    template<typename Sequence>
    typename mpl::back<Sequence>::type&
    back(Sequence& seq)
    {
        return mpl::back<Sequence>::result(seq);
    }

    template<typename Sequence>
    typename mpl::back<Sequence>::type const&
    back(Sequence const& seq)
    {
        return mpl::back<Sequence>::result(seq);
    }

but at some point I got rid of run-time 'result()' stuff in sequence
algorithms under the flag of simplification :). Needless to say that now I
think it was a mistake :).
 
> > One particular commonality that I was talking about is 
> > (IMO) in tuple algorithms and iterators. For example, as 
> > far as I can see, your 'for_each' and my 'for_each' do 
> > pretty much the same thing, except that mine allows
> > function object to change its type on each step of 
> > iteration (and ignoring the fact that my compile-time 
> > check for iterators' equality is kind of strange :).
> 
> Strange compared to which other compile-time iterator 
> equality check? ;) I don't see any other way to do that: 
> your way is exactly the same way as I came up with. 

Well, at least yours is hided inside of the iterator type itself :).

> Unless anyone can think of a better way to compare 
> equality of iterators at compile time (than comparing the 
> type of the list they point at) I think we can enshrine that 
> as the Normal Way To Do It.

It probably is.

> 
> The thing where the function object itself can change type is 
> actually a neater way to do what I've been trying to do all 
> along. I had the function object calling a Thingy that the 
> user could specialise. 

I like your names :). I am afraid I don't have enough information to analyze
how different our _applications_ of the tuple algorithms are (but from what
you've said, it seems that they are be different), but my main motivation to
give a function object a possibility to change its type was to allow one to
accumulate internal state on each step of iteration; I guess I need to see
some examples to be able to grasp a need for specialization here :).

> _Some_ way of doing that kind of thing seems fundamental 
> to tuple algorithms, since the bigger the tuple the more likely 
> it is to contain a type that requires special treatment. Not to 
> mention pointers and references which both also often seem
> to require special treatment.
> 
> I shall have to do some thinking about that. Hmm.

Sure. 

--
Aleksey