https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #15 from Jason Merrill ---
*** Bug 66841 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #14 from Jason Merrill ---
Author: jason
Date: Fri Jul 17 17:43:09 2015
New Revision: 225959
URL: https://gcc.gnu.org/viewcvs?rev=225959&root=gcc&view=rev
Log:
PR c++/66092
PR c++/66834
* gcc/cp/pt.c (coerce_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #13 from Jason Merrill ---
(In reply to Andrew Sutton from comment #12)
> I don't think that's a good idea. It means the template-id would be
> characterized as an atomic constraint for purposes of partial
> ordering. You lose the abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #12 from Andrew Sutton ---
> So it seems that applying the DR 1430 tentative resolution to concepts
> severely
> limits the usability of variadic concepts, and we should reconsider that, so
> that instead we delay normalization of te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #11 from Jason Merrill ---
Author: jason
Date: Tue Jul 14 04:11:11 2015
New Revision: 225758
URL: https://gcc.gnu.org/viewcvs?rev=225758&root=gcc&view=rev
Log:
PR c++/66092
PR c++/66834
* gcc/cp/pt.c (coerce_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #10 from Jason Merrill ---
(In reply to Jason Merrill from comment #9)
So it seems that applying the DR 1430 tentative resolution to concepts severely
limits the usability of variadic concepts, and we should reconsider that, so
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #9 from Jason Merrill ---
(In reply to Jason Merrill from comment #8)
> I think we should reconsider the rule against partial specialization of a
> variable concept, as that seems like the right way to handle this situation.
Except t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #8 from Jason Merrill ---
I think we should reconsider the rule against partial specialization of a
variable concept, as that seems like the right way to handle this situation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #7 from Andrew Sutton ---
> I would expect a partial ordering to prefer the two-parameter overload in that
> case. But yeah, it's a separate issue.
The problem is that partial ordering doesn't apply to template
parameters whose argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #6 from Eric Niebler ---
Exhaustively overloading Constructible to avoid the kind mismatch and the
ambiguity runs into a different problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841
I haven't filed an issue for the ambiguity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #5 from Eric Niebler ---
I would expect a partial ordering to prefer the two-parameter overload in that
case. But yeah, it's a separate issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #4 from Casey Carter ---
I conjecture that Constructible() is ambiguous, since both templates will
specialize for it. I was thinking:
template
concept bool Constructible() {
return requires {
T{};
};
}
template
concept boo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #3 from Eric Niebler ---
I was thinking that overloading the Constructible concept would be a conforming
way to express this, but it doesn't seems to work. Any clue why?
template
concept bool Same = __is_same_as(T, U);
template
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #2 from Andrew Sutton ---
I think that this is invalid too. There's an expansion from an
uninstantiated template argument pack into a pair of template
parameters.
I think the program must be ill-formed in this case. It's not possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #1 from Jason Merrill ---
This was introduced by my patch for bug 66092, applying the tentative
resolution of core issue 1430 to concepts as well as alias templates. This
makes sense to me since they have the same issue of needing to
15 matches
Mail list logo