220 26113 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: static_if, constraints, concepts, and definition checking Date: Tue, 31 May 2016 12:47:55 +0300 Lines: 265 Approved: news@gmane.org Message-ID: References: <097eaff2-2250-4c12-a764-1647de0d9a99@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1464688079 20670 80.91.229.3 (31 May 2016 09:47:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 May 2016 09:47:59 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC5JHI7A7ALRBTF3WW5AKGQERKDM4WY@isocpp.org Tue May 31 11:47:58 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f71.google.com ([209.85.192.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b7gHG-00064O-03 for gclcip-std-proposals@m.gmane.org; Tue, 31 May 2016 11:47:58 +0200 Original-Received: by mail-qg0-f71.google.com with SMTP id e93sf352361267qgf.3 for ; Tue, 31 May 2016 02:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=6WLxXrfABH/FjpRwWc33VZZPOGdYq92J2BQ/8tPf6rg=; b=OeNerZVkkJ8p+0Kx6vt/6dBNJz+DmFzrCkPHhngglFxusLSe0p5kqYbjXaGslWsJrQ ZapYA9KY2sqOkekR2Lf5x3L4R/te9guR31Yy/fjKaGNJLcr9wZ9bWccz8ZgEW+su/+6s Z6EkTwrjw75jwmnNfCMFqr1+b/Qq71ig2yFOYxJrQytgXcxVrj05VMjj+k1CKhoQK76G 78SAbZ58tGXTZGtqLUWm/GsMcDZf0i5VpBcs6EONVhkitxZZe72UZAeTHS7haYj/IQuX E/6BDvqGepDW38XjgRA+v0vXz8i2vezy0MId0qn7fzYRZmzxvld0jtPVAwJtZK3sZkMY LHSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6WLxXrfABH/FjpRwWc33VZZPOGdYq92J2BQ/8tPf6rg=; b=cJWWnYovCnc3yDLg+GEUYcgDv6ZwMVAZxtamX5MLV/GKVntGXzxd6vtL1hf+GhbZrO Bm+qKpk+9bECVF+VVznZd3F1wY5rdvsuOIEZaF5wS7MBrS9VB/uBCKXosQs7MS3zR3L2 gyf0F5UsIahsVnJa0gD01EEGpj7XCUa5EODYTwmekBdkBuI9YbshkMYijhmlU5feb+gA 3PMT3j8773t+fPILy3cM6C4pPZ1aocbS6KLgHfp9GGqXwKvS6cwBaMlZ+/DRT0S0Vv5z Ea6lE/XPIAvcXC2pA6nPAnkuO9S/4IO8kd1OQdlJnHR+Uomb57wBE2MHI5cqWaB0a2Uq CZkQ== X-Gm-Message-State: ALyK8tImV+/vdzDvSh6ztlAOrE6lDVJARRg3rxYkK0MbbAF9XFZSRZHpigFo9yuMY4bQtg== X-Received: by 10.237.46.199 with SMTP id k65mr22741278qtd.23.1464688076951; Tue, 31 May 2016 02:47:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.81.112 with SMTP id e103ls4924056qgd.64.gmail; Tue, 31 May 2016 02:47:55 -0700 (PDT) X-Received: by 10.176.69.66 with SMTP id r60mr17266795uar.120.1464688075902; Tue, 31 May 2016 02:47:55 -0700 (PDT) Original-Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com. [2607:f8b0:400c:c05::236]) by mx.google.com with ESMTPS id d3si23289829vkf.143.2016.05.31.02.47.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2016 02:47:55 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400c:c05::236 as permitted sender) client-ip=2607:f8b0:400c:c05::236; Original-Received: by mail-vk0-x236.google.com with SMTP id a6so44167836vkg.3 for ; Tue, 31 May 2016 02:47:55 -0700 (PDT) X-Received: by 10.31.202.71 with SMTP id a68mr16362228vkg.79.1464688075459; Tue, 31 May 2016 02:47:55 -0700 (PDT) Original-Received: by 10.103.126.145 with HTTP; Tue, 31 May 2016 02:47:55 -0700 (PDT) In-Reply-To: <097eaff2-2250-4c12-a764-1647de0d9a99@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400c:c05::236 as permitted sender) smtp.mailfrom=ville.voutilainen@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:26113 Archived-At: On 31 May 2016 at 02:30, Nicol Bolas wrote: >> If you need to use a legacy template in the implementation of a >> constrained template, and you don't >> want to constrain the legacy template (possibly because it needs to >> work with pre-c++20 code, possibly >> because it does something that shouldn't appear in the interface of >> your constrained template, and it >> still always works within your constraints). > > > This right here is part of the disconnect we have, and it's part of the > reason why I wanted to invent specific terms to discuss these separate and > distinct ideas. However, I don't really care what they're called, so long as > the distinction is clear. So I'll try to use your language for them. > > The interface for `range::sort` is well specified. The range it is provided > must conform to a specific set of requirements, and the function it is given > (if any) must also conform to a specific set of requirements. That creates a > contract between the callee and the caller. > > In order for a contract to work, this contract must be binding on both > sides. The callee must provide at least the required interfaces, much like > the person who derived from a base class must implement the pure-virtual > members. However, the caller must also not attempt to perform any operations > other than those for which the contract is valid. Much like the user of a > base class cannot call functions which were not declared as part of the > interface. > > There is absolutely no reason for an implementation of `range::sort` to > violate its contract, to use its parameters in a way that violates the rules > that govern its functionality. Indeed, those rules were created under the > expectation that implementations will not need to do so. I'm really not concerned about contract violations. What I'm concerned about is code that doesn't violate a contract, but will be claimed to violate a contract by definition checking. Code like constrained templates using legacy templates in their implementation. Or code like constrained templates using tracing/debugging/telemetry facilities. Such implementation details should not affect the interface, but all definition checking mechanisms described thus far make such interface effects unavoidable. > > An "interface constraint" is not a contract. It is merely a declaration of > requirements on the user's part. A "definition constraint" is a real, live, > compiler-verified contract between the caller and the callee. > > What I'm saying are the following: > > 1) We need to have both "interface constraints" and "definition > constraints". There seems to be much less need for the latter than the former. > 2) We should declare them using similar syntax. Fine by me. > 3) We need to be able to use both in similar ways, likely with > interoperation between them. Depends on what those "similar ways" are. I want to opt in to definition checking. > > 4) We need "definition constraints" to be part of the concepts syntax from > day one, even if we don't actually require compilers to check the > definitions. That way, people (including the Range TS) can write its > concepts as definition constraints, with the expectation that, once compiler > checking comes online, they will handle it. I don't agree. These definition constraints, as they were in C++0x Concepts or in other vague descriptions of them as a mandatory always-on facility, don't work, because they only ever work if every template ever used in the whole system is constrained. That, as I said, is a useless non-starter. >> That's an incorrect simplification. Concepts as proposed, and the >> constraint language they use, >> provide a means to write generic interfaces. > > > Templates provide a means to write generic interfaces. No they don't. They provide a means to write generic implementations, but they provide no means to write generic interfaces. Unless all you ever want an interface to be able to specify is whether something is a reference or a pointer. I don't find that sufficient. > Concepts TS simply provides a means to write explicitly constrained generic > interfaces. Interfaces who's usage is verified by the compiler, and > definitions for which can be SFINAE'd away based on their use. These are > things we would have used `enable_if` and similar tools to handle before. > Now we want to use Concepts TS for them. Correct on that part. > Boost Lambda was a library way to introduce lambda expressions. We got a > replacement in the form of a language feature to do that. How is this > different, exactly? Perhaps it isn't. But my view on Concepts vs. enable_if and lambdas vs. Boost.Lambda is different than yours; my view is that the language facilities solve the fundamental problem better, not that they are 'replacements'. There's a subtle difference there. >> enable_if can be abused >> to do something remotely like that in a very >> indirect manner, > I'm curious: what other use for `enable_if` is there than constraining > template instantiations? The point is that enable_if is a fairly low-quality tool for constraining templates. Especially for constraining interface. Your choice of words "constraining instantiations" is of course more generic, and enable_if indeed does that, but it's not a good tool for constraining interfaces, which is a much smaller set of things than constraining instantiations. >> > at P0225, all of the arguments made there in favor of Concepts TS talk >> > about >> > its use only as a replacement for `enable_if`. Concepts doesn't disturb >> > the >> >> They talk about using Concepts to solve problems that are annoyingly >> difficult to solve with enable_if. The only >> aspect where Concepts are a replacement to enable_if is enable_if >> being currently the only solution to any >> such problems. > > > And... it currently is. In C++14, if you want to constrain a template, you > must do so with `enable_if` or some similar tool. So, I'm not sure what > you're trying to say here. Again, the paper talks about solutions to fundamental problems, not about solutions to replace abuses of enable_if. >> The ability to write constrained interfaces for generic code without >> disturbing deduction is of fundamental >> importance. With enable_if, I need to resort to all sorts of brittle >> nonsense to get to that destination. >> With Concepts, I can write such interfaces directly, without separate >> traits-wrapped logical combinations in >> the declaration. I can emulate that goal to some extent; I recommend >> looking at libstdc++'s and the >> tuple constructors for some examples. I have almost-predicates which >> are constexpr functions. I still need >> to wrap them inside an enable_if to constrain interfaces. With >> Concepts, such wrapping becomes completely >> unnecessary. I get constrained interfaces without the 'gymnastics' >> mentioned below, and that's not such >> syntactic sugar. I also get a well-defined and well-ordered constraint >> evaluation model that makes it far easier to write constraints >> and their combinations. And I get all that for both templates and >> non-templates. > > > At no point was I arguing against the the merits of "interface constraints"; > I was simply restating and summarizing your position within the larger body > of thought on concepts. Specifically, that your points all matter only to > the interface, not to the definition. Well, perhaps that's because there's far more need to constrain interfaces than there is to constrain a definition. :) >> > Concepts are about something more than merely being `enable_if` without >> > the >> > crappy syntax. Constraints simply say when a function/type may or may >> > not >> > exist. Concepts make a much stronger statement about the meaning of a >> > piece >> > of code. A concept is a constraint, but it constrains both halves of the >> > code. >> >> Well, now you're talking about "Concepts" which may or may not >> materialize. > > > Sorry, but I don't read scare-quotes. Can you explain the difference between > "Concepts" and scare-quotes "Concepts"? Concepts as specified in the TS vs. Concepts that might also apply to definitions. >> The definition-checking half >> certainly hasn't materialized yet in any form that would be viable. >> And I have sufficient practical experience >> and evidence that I know that "Concepts" that constrain "both halves" >> of code so that they always constrain >> both the interface and the definition, without letting me constrain >> just the interface, are not worth the trouble. >> They are a useless non-starter for practical purposes where >> programmers need to deal with existing codebases, compatibility >> and migration paths. > > > I get that interface contracts aren't something you like to use. Please > explain why that means nobody should be allowed to use contracts either. I think you should've written 'definition' instead of 'interface' there. I am not strongly opposed to definition checking. What I'm opposed to is definition checking that is always on, and not being able to check just the interface. As I said, I have plenty of evidence that such mandatory definition checking will not work. It didn't work before, and all vague descriptions of how to supposedly do it with the new Concepts suffer from the very same problems as C++0x Concepts did. > >> > of static_if, a pure-constraint mechanism. Concepts-lite was a proposal >> > that >> > was made in response to a D-style static_if proposal (ironically, >> > `constexpr >> > if` is now more likely to see C++17 than Concepts TS). As such, it's >> > primary >> > focus is constraints, with full concepts as an optional extra. >> >> Revisionist history at its best. The work on Concepts Lite happened >> separately and before >> there ever was a proposal for a D-style static if for C++. > > > But the only publicly available paper trail dates the first concepts-lite > paper (N3580) 03/17/2013, while the first static_if papers (N3322 and N3329) > at 12/11/2011 and 01/10/2012, both over a year before. Indeed, N3580 was Well, if you read http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3351.pdf, you'll notice that it dates the Palo Alto meeting at August 4-9, 2011. Concepts Lite is the follow-up work of that. > also released in the same mailing at N3618, which was a comparison between > static_if and concepts-lite. So clearly, the authors of concepts-lite were > aware of the static_if proposals and considered them competition. > > Maybe there were things happening behind closed doors. But from the > information I have available, this is a reasonable description of the > sequence of events. Well, that latest description is remotely reasonable. Claiming that Concepts Lite was (just) a response to static if remains nonsense, and neither the paper trail or anything else supports that conjecture, you just pulled it out of your hat. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb2qtwiCrSArTbT7FYTk3Z2HaAZCciS2b7B0zV2-Eeonw%40mail.gmail.com. .