There is a very useful proposal that the EWG is considering that
discusses the use of decltype and auto to query types of expressions to
facilitate generic programming.

The paper also talks about the use of 'implicit templates' which provide
no new capability than that which is provided by decltype and auto, but
do serve as a convenience when writing generic functions.

Here's a link to the paper for all those who would like to read about
some very kool ideas:
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf)

I had two questions regarding the implicit templates feature whose
answers I failed to find in the paper:

1) Will we be able to combine 'implicit templates' with 'traditional
templates'

for e.g:

template<int N>
void array_op( auto (&arr)[N] ) { auto n = arr[0];  ... }

template< template<class,class> class TT >
void tt_op( TT<auto,auto> a, auto b, TT<auto,auto> c)
{
  ...
}


2) Will we be able to use decltype along with auto to capture relations
between template arguments
(even though auto by itself cannot be used to capture relations as the
paper notes)

for e.g:

void f(auto a, auto b) { }
[i.e: template<class A, class B> void f(A a, B b) { }]

// Captures relation
void f(auto a, decltype(a) b) { }
[i.e: template<class A> void f(A a, A b) { }]


thanks,
Faisal Vali

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> There is a very useful proposal that the EWG is considering that
> discusses the use of decltype and auto to query types of expressions to
> facilitate generic programming.
>
> The paper also talks about the use of 'implicit templates' which provide
> no new capability than that which is provided by decltype and auto, but
> do serve as a convenience when writing generic functions.
>
> Here's a link to the paper for all those who would like to read about
> some very kool ideas:
> (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf)
>
> I had two questions regarding the implicit templates feature whose
> answers I failed to find in the paper:
>
> 1) Will we be able to combine 'implicit templates' with 'traditional
> templates'
>
> for e.g:
>
> template<int N>
> void array_op( auto (&arr)[N] ) { auto n = arr[0];  ... }
>
> template< template<class,class> class TT >
> void tt_op( TT<auto,auto> a, auto b, TT<auto,auto> c)
> {
>   ...
> }
>

According to what I understand, I think that using auto is simply
a shorthcut for a template... so I think that from the compiler
point of view the followinf would be equivalent:

template <typename T> void f(T t) { }
void f(auto t);

And I suppose that I can even uses the type of the
auto variable using decltype

void g(auto x)
{
    decltype(x) tmp(x);

    std::vector<decltype(x)> myvector;
    myvector.push_back(x);

    std::cout << typeid(x).name();
}

>
> 2) Will we be able to use decltype along with auto to capture relations
> between template arguments
> (even though auto by itself cannot be used to capture relations as the
> paper notes)
>
> for e.g:
>
> void f(auto a, auto b) { }
> [i.e: template<class A, class B> void f(A a, B b) { }]
>
> // Captures relation
> void f(auto a, decltype(a) b) { }
> [i.e: template<class A> void f(A a, A b) { }]
>
>

>From my understanding that uses of decltype is prohibited. That
is if we want a type to depend on another one, we have to uses
standard template syntax.

But IMHO, we should allows your sample... and we should find a
way to make it works with template classes also:

    template <typename T> class A
    {
        T t;
       public:
        A (T t_) : t(t_);
    };

    // I want to define a type like std::pair<U, A<U> > where is
    // would be determined by the compiler. I suggest using auto
    // combined with typename for that:
    std::pair<auto typename T, A<T> > my_pair = std::make_pair(29, 33);

    This should works since A allows construction from an in and std::pair
    have a template constructor that should do the conversion.

> thanks,
> Faisal Vali
>

And after reading the document, I have my own comments:


1) I think that we should support return type deduction even
when multiple returns are used and we should uses the rules
that are used with ? : operator (but without reference).

That is:

    int i1, i2;
    auto h() { return cond ? i1 : i2; }
    auto h() { if (cod) return i1; else return i2; }

should both returns an int.

If we want a reference, we should write auto &h();


2) We should be able to have some control over weither
a reference or a value (or a constant reference) is used
when using either auto or decltype.

In the first case, I think we can only add to the type :
    auto &ri = i;
    auto const ci = i;
    auto const & rci = i;
    std::pair<auto, auto> p = std::make_pair(i, 25.8);


3) When a function is declared using decltype for the
return value, I think it should be optional when defining
the function to repeat it.

    auto f(int a) -> decltype(a);

    auto f(int a) { return a + 2; } // should be ok since it match

4) We should remove the restriction that member variables
(including this) are not in scope for a decltype inside a class.
This would be usefull in some cases:

a) for a cache (for ex. the result of a multiplication)

b) This would allows (with some helper functions) to
have member function that returns appropriate type
depending on weither this is const:

    template <typename T, typename U>
    U make_type(T *, U);    // definition not required

    // Specialization...
    template <typename T, typename U>
    U const make_type(T const *, U);

    class C {
        int member;

       public:
            // Returns a reference to a member with proper constness.
            // Note the uses of auto after the member name.
            auto get() auto ->
                decltype(make_type(this, member)) & { return member; }
    };

This would also works well when we need to capture the constness
inside a member function (since qualifier are otherwise removed)

In fact, if decltype is extended to allows to returns reference type
(where cv qualifier would never be removed), it could simplify the
syntax even more. Since decltype require (), I would suggest to
uses decltype &(expr or type) syntax. The previous example could
be rewritten as:

    class C {
        int member;

    public:
        auto get() auto -> decltype &(member) { return member; }

        // or even (still better)
        auto get2() auto -> decltype & { return member; }
    };

We might support other qualification (like cv).


5) We should support returning a type that depend on another:

    auto ff(int a) -> std::vector<declspec(a)>;

    auto ff(int a) {
        std::vector<declspec(a)> result;
        result.push_back(a);
        result.push_back(a + 1);
        result.push_back(a + 2);
        return result;
    }


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]