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

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

[eric.niebler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

            Bug ID: 66834
           Summary: [concepts] concept parameter kind mismatch causes hard
                    error
           Product: gcc
           Version: c++-concepts
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Before rev 225651 (the fix for #66758), the following worked. It no longer
does. Not sure if it's legit.

template <class From, class To>
concept bool ExplicitlyConvertible =
  requires (From&& f) {
    static_cast<To>((From&&)f);
  };

template <class T, class... Args>
concept bool Constructible =
  ExplicitlyConvertible<Args..., T> ||
  requires (Args&&... args) {
    T{((Args&&)(args))...};
  };

template <class T, class...Args>
constexpr bool constructible() { return false; }

Constructible{T, ...Args}
constexpr bool constructible() { return false; }

int main() {}


Yields:

/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp: In function ‘constexpr
bool Constructible()’:
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:9:5: error: pack
expansion argument for non-pack parameter ‘From’ of concept ‘template
<class From, class To> constexpr const bool ExplicitlyConvertible<From, To>’
     ExplicitlyConvertible<Args..., T> ||
     ^
/cygdrive/c/Users/eric/Code/cmcstl2/test/iterator.cpp:1:11: note: declared here
 template< class From, class To >
           ^
>From gcc-bugs-return-492008-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 10 18:36:43 2015
Return-Path: <gcc-bugs-return-492008-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 129817 invoked by alias); 10 Jul 2015 18:36:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 125011 invoked by uid 48); 10 Jul 2015 18:36:38 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/54521] g++ fails to call explicit constructors in the second step of copy initialization
Date: Fri, 10 Jul 2015 18:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-54521-4-RIo3ZhZOXk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54521-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54521-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00898.txt.bz2
Content-length: 468

https://gcc.gnu.org/bugzilla/show_bug.cgi?idT521

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Mine.

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
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 substitute
dependent arguments into the template, in this case during normalization.

So I think your example is invalid, but it could use some discussion in core.

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

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #2 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
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
to substitute a single pack through the two parameters declared for
ExplicitlyConvertible in order to normalize the constraint.

The TS is silent on this, but the resolution should be the same as that of
1430.

Andrew Sutton


On Fri, Jul 10, 2015 at 10:48 PM, jason at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
>
> --- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
> 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 substitute
> dependent arguments into the template, in this case during normalization.
>
> So I think your example is invalid, but it could use some discussion in core.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

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

[eric.niebler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #3 from Eric Niebler <eric.niebler at gmail dot com> ---
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 <class T, class U>
concept bool Same = __is_same_as(T, U);

template <class T, class U>
concept bool ExplicitlyConvertible() { return
  Same<T, U> ||
  requires(T&& t) {
    static_cast<U>((T&&)(t));
  };
}

template <class T, class... Args>
concept bool Constructible() { return
  ExplicitlyConvertible<Args..., T>() ||
  requires (Args&&... args) {
    T{ (Args&&)(args)... };
  };
}

template <class T, class U>
concept bool Constructible() { return
  ExplicitlyConvertible<U, T>() ||
  requires (U&& u) {
    T{ (U&&)(u) };
  };
}

template <class T, class U>
  requires Constructible<T, U>()
constexpr bool f() { return false; }

template <class T, ExplicitlyConvertible<T> >
constexpr bool f() { return true; }

static_assert(f<int,int>(), "");
static_assert(f<int,long>(), "");

struct A {
  A(int);
};
struct B {
  explicit B(int);
};
static_assert(f<A, int>(), "");
static_assert(!f<B, int>(), "");


Yields:

/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:32:25: error:
invalid reference to function concept ‘template<class T, class U> constexpr
bool Constructible()’
   requires Constructible<T, U>()
                         ^
/cygdrive/c/Users/eric/Code/cmcstl2/test/core_concepts.cpp:48:1: error: static
assertion failed
 static_assert(!f<B, int>(), "");
 ^

I can't make sense of the error. Is this just a bug?
>From gcc-bugs-return-492040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 11 17:38:57 2015
Return-Path: <gcc-bugs-return-492040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 95030 invoked by alias); 11 Jul 2015 17:38:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 94993 invoked by uid 48); 11 Jul 2015 17:38:53 -0000
From: "Casey at Carter dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
Date: Sat, 11 Jul 2015 17:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: c++-concepts
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Casey at Carter dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66834-4-Vi5Gn6MNZZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66834-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66834-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00930.txt.bz2
Content-length: 837

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf834

--- Comment #4 from Casey Carter <Casey at Carter dot net> ---
I conjecture that Constructible<T, U>() is ambiguous, since both templates will
specialize for it. I was thinking:

template <class T>
concept bool Constructible() {
  return requires {
    T{};
  };
}

template <class T, class U>
concept bool Constructible() {
  return ExplicitlyConvertible<U, T>() ||
  requires (U&& u) {
    T{ (U&&)(u) };
  };
}

template <class T, class First, class Second, class... Rest>
concept bool Constructible() {
  return requires (First&& first, Second&& second, Rest&&... rest) {
    T{ (First&&)first, (Second&&)second, (Rest&&)(rest)... };
  };
}

which has no such ambiguities of specialization. (This is getting a little
off-topic for this bug report - we should takes this offline.)

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

[eric.niebler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #5 from Eric Niebler <eric.niebler at gmail dot com> ---
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

[eric.niebler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #6 from Eric Niebler <eric.niebler at gmail dot com> ---
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/partial order problem. Should I, or
is that by design?

Either the kind mismatch problem needs to be fixed, or issue #66841. Right now
I don't seem to have a way to express what I'm trying to express.

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
(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 that would still run into the DR 1430 issue: a requires-clause that uses
a pack expansion would normalize using the primary template defined with a
parameter pack, even if a later instantiation of that requires-clause would
work better with a different partial specialization.

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
(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 instead we delay normalization of template-ids with variadic arguments
until instantiation time.

The restriction on expansion arguments to non-expansion parameters initially
applied to all variadic templates until N2555, which Eric was also involved
with...

I guess I'll revert my change for the moment.

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
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_template_parms): Revert earlier change.

Removed:
    branches/c++-concepts/gcc/testsuite/g++.dg/concepts/dr1430.C
Modified:
    branches/c++-concepts/ChangeLog.concepts
    branches/c++-concepts/gcc/cp/pt.c

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

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #12 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
> 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 template-ids with variadic arguments
> until instantiation time.
>
> The restriction on expansion arguments to non-expansion parameters initially
> applied to all variadic templates until N2555, which Eric was also involved
> with...

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 ability to order on constraints within the
concept, which means you're no better off than using a type trait for
the definition.

I would make the following observations:

1. Variadics require meteaprogramming and pattern matching
2. The constraint are not intended to be turing complete, so we can't
reason about metaprograms
3. There may be useful logical extensions to the constraint language
for working with variadics in principled ways
4. Some variadic constraints might be useful as core language
constraints (intrinsics).

Plus, I have a feeling that I'm going to to have to re-think the
entire concept definition and requires-expression bit when we propose
concepts for C++. There were too many NB comments to ignore.

Andrew

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> ---
(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 ability to order on constraints within the
> concept, which means you're no better off than using a type trait for
> the definition.

True, I guess it's a trade-off between power and ease of use.  Should I
re-apply the change to coerce_template_parms?

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
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_template_parms): Re-apply earlier change.

Added:
    branches/c++-concepts/gcc/testsuite/g++.dg/concepts/dr1430.C
Modified:
    branches/c++-concepts/ChangeLog.concepts
    branches/c++-concepts/gcc/cp/pt.c

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

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> ---
*** Bug 66841 has been marked as a duplicate of this bug. ***

[Bug c++/66834] [concepts] variadic concepts and DR 1430

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anthony.ajw at gmail dot com

--- Comment #17 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 79686 has been marked as a duplicate of this bug. ***