Hi,
Yes, that is intended. Changing that could mean that the meaning of
code depends on what max depth the user selected.
Indeed. Yesterday I wondered what would happen if the front-end had a way to
detect, in some very specific and special cases only of course, really infinite
recursions,
.. another thought I had, less esoteric ;) is the following: we use
tf_none for two rather different reasons: for SFINAE and to avoid
recursive Error routines calls, when we call tsubst (... tf_none, ...)
from dump_template_bindings.
I understand, given your reply, that in general in the
On 08/09/2013 08:43 AM, Paolo Carlini wrote:
Yes, that is intended. Changing that could mean that the meaning of
code depends on what max depth the user selected.
Indeed. Yesterday I wondered what would happen if the front-end had a way to detect, in
some very specific and special cases
Hi,
Florian Weimer fwei...@redhat.com ha scritto:
On 08/09/2013 08:43 AM, Paolo Carlini wrote:
Yes, that is intended. Changing that could mean that the meaning of
code depends on what max depth the user selected.
Indeed. Yesterday I wondered what would happen if the front-end had a
way to
On 08/09/2013 09:28 AM, Paolo Carlini wrote:
I see. You know, I was trying to figure out the logic other compilers - two of
them, actually - are following, because the really appear to sfinae away
infinite recursions. Was trying to imagine cases in which it would be safe.
Could their
Hi,
Florian Weimer fwei...@redhat.com ha scritto:
Could their behavior just be bugs? Depending on their error recovery
implementation, not flagging infinite recursion as a hard error in
SFINAE context could be an easy mistake to make.
Sure can be. In a sense, as I tried to explain in another
On Thu, Aug 8, 2013 at 6:40 PM, Jason Merrill ja...@redhat.com wrote:
On 08/08/2013 03:54 PM, Paolo Carlini wrote:
the really interesting one is decltype28.C, which we don't reject
anymore, we simply accept it. What is happening is that the overload
which leads to excessive template
On Fri, Aug 9, 2013 at 2:13 AM, Florian Weimer fwei...@redhat.com wrote:
On 08/09/2013 08:43 AM, Paolo Carlini wrote:
Yes, that is intended. Changing that could mean that the meaning of
code depends on what max depth the user selected.
Indeed. Yesterday I wondered what would happen if the
On Fri, Aug 9, 2013 at 2:33 AM, Florian Weimer fwei...@redhat.com wrote:
On 08/09/2013 09:28 AM, Paolo Carlini wrote:
I see. You know, I was trying to figure out the logic other compilers -
two of them, actually - are following, because the really appear to sfinae
away infinite recursions.
On Fri, Aug 9, 2013 at 2:13 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
.. another thought I had, less esoteric ;) is the following: we use tf_none
for two rather different reasons: for SFINAE and to avoid recursive Error
routines calls, when we call tsubst (... tf_none, ...) from
Hi,
On 08/09/2013 10:46 AM, Gabriel Dos Reis wrote:
I think we should find ways to have the pretty printer in the
diagnostic framework stop trying to redo most of the work done by the
type checker. In its current form, that is fragile. -- Gaby
Yeah. That tsubst (..., tf_none, ...) from
On Fri, Aug 9, 2013 at 4:28 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 08/09/2013 10:46 AM, Gabriel Dos Reis wrote:
I think we should find ways to have the pretty printer in the diagnostic
framework stop trying to redo most of the work done by the type checker. In
its current
On 08/08/2013 03:54 PM, Paolo Carlini wrote:
the really interesting one is decltype28.C, which we don't reject
anymore, we simply accept it. What is happening is that the overload
which leads to excessive template instantiation depth is SFINAE-ed away
and the other one wins! Thus, this is the
13 matches
Mail list logo
