msalters wrote:
> Vladimir Marko wrote:
[snip]
> It's a bit over the top, I think. I don't doubt that adding all
> built-in types and the built-in operations on them can be done;
> that's a fixed set.

I think the language should minimize the differences between
built-in types and UDTs. And I don't know what built-in types
have to do with the topic, unless you are trying to suggest
that the template
.  template <class T,class U>
.  decltype((*(T*)0)+(*(U*)0)) add(const T& t,const U& u);
should only be instantiated with built-in types. Are you?

[snip]
> E.g. are these function templates identical?
>
> typename decltype(decltype((*(T*)0)+(*(U*)0))::X
>     foo(T t,U u);
> typename decltype(decltype((*(U*)0)+(*(T*)0))::X
>     foo(T t,U u);

No, they are different. The expressions (*(T*)0)+(*(U*)0)
and (*(U*)0)+(*(T*)0) need not be of the same type if user
defined operators + are considered (the operator + is used
only to give an exact quote from the proposal, it seems that
"bar(*(T*)0,*(U*)0)" would better express the intent).

> If not, consider the instantiations foo<int,int> and foo<int,int>.
> What stops a linker from issuing an ODR violation?

Correct name mangling. There is _no_ ODR violation, in gcc
PR6424 discussion (link below) Gabriel Dos Reis refers to
std:14.5.5.1/5 which should IMHO apply also to the
not-yet-standardized decltype.

> > I would propose to allow any kind of expression inside sizeof
> > (and decltype) and explicitly add sizeof (and decltype)
> > expressions involving template-parameters to non-deduced contexts
> > (add a bullet to 14.8.2.4/4).
> >
> > I guess this could pose a serious trouble for implementers
> > (see for example the discussion at
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6424), but from the
> > user's perspective I see no better option.
>
> Doesn't fix the problem, as far as I can see it. And yor argument
> basically is "just make it work, dammit". That doesn't count.

Well, my statement is a little longer: "Just make it work,
dammit. Otherwise N1607's usability will be very limited."

> The
> real user perspective is better a limited feature, implemented in
> some compilers, than a perfect feature, implemented in none.
> There used to be a guideline stating that standards should follow
> implementations. export broke that, and the results are clear. I
> don't want a repeat of that.

I think that exported templates broke the well known system
of translation phases of C by splitting "translated TUs"
and "instantiation units". This was a fundamental change
and I do not propose anything _that_ radical.

> I can imagine that we restrict the problem by disallowing decltype
> in the declaration of exported templates. The reason is that name
> mangling is a lot easier if the scope is restricted to a single
> TU. Still, we'd have the problem of ensuring that there's only one
> definition of every template member etc.

That problem is already being handled for different expressions
in the function template signature including the sizeof
expressions. AFAICT the only question that remains is which
expressions can be mangled and which can not.

Regards,
Vladimir Marko

---
[ 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                       ]

The decltype and auto proposal (revision 3: N1607) presents

.  template <class T,class U>
.  decltype((*(T*)0)+(*(U*)0)) add(const T& t,const U& u);

as a valid declaration (if the proposal is accepted). On the
other hand, in the active core issue #339,
(http://www2.open-std.org/jtc1/sc22/WG21/docs/cwg_active.html#339),
I read

.  The core working group liked the idea of a restriction that
.  says that expressions inside sizeof in template signature
.  contexts must be otherwise valid as nontype template argument
.  expressions (i.e., integer operations only, limited casts).

and

.  It was also noted that if typeof (whatever it is called) is
.  added, there may be a similar issue there.

If such a restriction really applied to decltype, the declaration
above would be invalid. AFAICT every non-trivial use of decltype
in a template function declaration would be invalid. And for me
this would render my favorite proposal useless.

I would propose to allow any kind of expression inside sizeof
(and decltype) and explicitly add sizeof (and decltype)
expressions involving template-parameters to non-deduced contexts
(add a bullet to 14.8.2.4/4).

I guess this could pose a serious trouble for implementers
(see for example the discussion at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6424), but from the
user's perspective I see no better option.

Any comments?

Regards,
Vladimir Marko

---
[ 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                       ]

Vladimir Marko wrote:
> The decltype and auto proposal (revision 3: N1607) presents
>
> .  template <class T,class U>
> .  decltype((*(T*)0)+(*(U*)0)) add(const T& t,const U& u);
>
> as a valid declaration (if the proposal is accepted). On the
> other hand, in the active core issue #339,
> (http://www2.open-std.org/jtc1/sc22/WG21/docs/cwg_active.html#339),
> I read
>
> .  The core working group liked the idea of a restriction that
> .  says that expressions inside sizeof in template signature
> .  contexts must be otherwise valid as nontype template argument
> .  expressions (i.e., integer operations only, limited casts).
>
> and
>
> .  It was also noted that if typeof (whatever it is called) is
> .  added, there may be a similar issue there.

It's a bit over the top, I think. I don't doubt that adding all
built-in types and the built-in operations on them can be done;
that's a fixed set.

> If such a restriction really applied to decltype, the declaration
> above would be invalid. AFAICT every non-trivial use of decltype
> in a template function declaration would be invalid. And for me
> this would render my favorite proposal useless.

True. E.g. are these function templates identical?

typename decltype(decltype((*(T*)0)+(*(U*)0))::X
    foo(T t,U u);
typename decltype(decltype((*(U*)0)+(*(T*)0))::X
    foo(T t,U u);

If not, consider the instantiations foo<int,int> and foo<int,int>.
What stops a linker from issuing an ODR violation?

> I would propose to allow any kind of expression inside sizeof
> (and decltype) and explicitly add sizeof (and decltype)
> expressions involving template-parameters to non-deduced contexts
> (add a bullet to 14.8.2.4/4).
>
> I guess this could pose a serious trouble for implementers
> (see for example the discussion at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6424), but from the
> user's perspective I see no better option.

Doesn't fix the problem, as far as I can see it. And yor argument
basically is "just make it work, dammit". That doesn't count. The
real user perspective is better a limited feature, implemented in
some compilers, than a perfect feature, implemented in none.
There used to be a guideline stating that standards should follow
implementations. export broke that, and the results are clear. I
don't want a repeat of that.

I can imagine that we restrict the problem by disallowing decltype
in the declaration of exported templates. The reason is that name
mangling is a lot easier if the scope is restricted to a single
TU. Still, we'd have the problem of ensuring that there's only one
definition of every template member etc.

Regards,
Michiel Salters

---
[ 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                       ]