From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2410 invoked by alias); 14 Nov 2013 10:20:52 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2277 invoked by uid 55); 14 Nov 2013 10:20:47 -0000 From: "walter.mascarenhas at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/59056] ambiguous call to function template overloads not diagnosed Date: Thu, 14 Nov 2013 10:20: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: unknown X-Bugzilla-Keywords: accepts-invalid X-Bugzilla-Severity: normal X-Bugzilla-Who: walter.mascarenhas at gmail dot com X-Bugzilla-Status: NEW 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: In-Reply-To: References: 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: 2013-11/txt/msg01352.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 --- Comment #9 from Walter Mascarenhas --- 1) I just wrote that Richard's paragraph, IN ITSELF, does not explain why things are as they are. I did not write that there aren't other reasons to justify the standard's decisions. 2) As I wrote, GCC does depend on the value of check< Foo >() in order to decide whether or not the code is ambiguous: If we provide an specialization template <> constexpr bool check >() {return false;} then the ambiguity goes away. Of course, this specialization changes the code and brings in other issues. I just want to point out, naively, that the value of check< Foo >() is relevant for GCC. 3) In my naive user point of view, I believed that Richard's observation that "the only available definition of check always return true" would imply that template struct Bar() > >{}; would be essentially equivalent to template struct Bar{}; and this looks less specialized than template <> struct Bar< Foo, void >{}, This was my naive view. If the standard says otherwise then there is no point in arguing about it. walter. On Thu, Nov 14, 2013 at 1:04 AM, richard-gccbugzilla at metafoo dot co.uk < gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 > > --- Comment #8 from Richard Smith co.uk> --- > (In reply to Walter Mascarenhas from comment #7) > > In itself, Richard's paragraph "Morally, the function should > ambiguous... " > > implies that the code below is ambiguous. However, it > > compiles just fine with gcc 4.8.1, because gcc also takes into > > account the information that check< Foo >() is false > > in order to discard the specialization with the enable_if. In > > other words, the X in check is not completely arbitrary, > > it my be related to Foo. > > GCC can't instantiate check with a dependent type Ty, because that's > not a > meaningful thing to do. And it's not allowed to use Foo, because > partial > ordering of templates does not depend on the actual deduced arguments for > the > template specialization (it orders the templates themselves, not their > specializations). Also, the only available definition of check always > returns > true. So I really don't see how that could be the case. > > -- > You are receiving this mail because: > You reported the bug. >