[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-08-04 Thread jason at gcc dot gnu.org
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. ***

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-17 Thread jason at gcc dot gnu.org
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-14 Thread jason at gcc dot gnu.org
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-14 Thread andrew.n.sutton at gmail dot com
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-13 Thread jason at gcc dot gnu.org
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-13 Thread jason at gcc dot gnu.org
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-13 Thread jason at gcc dot gnu.org
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-13 Thread jason at gcc dot gnu.org
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.

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-12 Thread andrew.n.sutton at gmail dot com
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-11 Thread eric.niebler at gmail dot com
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-11 Thread eric.niebler at gmail dot com
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.

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-11 Thread Casey at Carter dot net
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-11 Thread eric.niebler at gmail dot com
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-11 Thread andrew.n.sutton at gmail dot com
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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

2015-07-10 Thread jason at gcc dot gnu.org
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