220 32297 <3f13697d-a5d6-d802-68b6-291c79f0b041@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Solving the std::swap embarrassment*? Date: Thu, 4 May 2017 02:54:14 +0200 Lines: 314 Approved: news@gmane.org Message-ID: <3f13697d-a5d6-d802-68b6-291c79f0b041@wanadoo.fr> References: <201705022023.38635.marc.mutz@kdab.com> <50d6b1fa-618f-42c4-893e-3c20a855ea80@isocpp.org> <991619cd-f935-43e0-85a5-b417cd6afe58@isocpp.org> <13f995f2-f92c-4a73-a8d5-b7dea6395d20@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0322D65C87AD79B2B0125222" X-Trace: blaine.gmane.org 1493859259 17958 195.159.176.226 (4 May 2017 00:54:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 May 2017 00:54:19 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBN7XVHEAKGQE3LB5KUQ@isocpp.org Thu May 04 02:54:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6523-0004VO-6J for gclcip-std-proposals@m.gmane.org; Thu, 04 May 2017 02:54:11 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id m82sf1228628lfg.0 for ; Wed, 03 May 2017 17:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-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=kz2ouu5rgB7holvcpQKvUKb3i8IsL+WyZDlVQd5W+xw=; b=pPpZBYIVlQLWSd62itIPv2MvIpz2JGuUm6M41cjSL4NNi+vyy0juISv/cVXoshJjTq OiNVpGMiSUa3+2EaCT6Bgm/PmHnY2JsBDZxPC1TKmBca6HFLvbtWNh3OfFyRrc+/ntq4 0i6xTcA9hVU6TJES67O3FW++pIcBsC9dp+Nqt8wVnobRPwzbXeR+dfJxZdcKOHPAt8sm WY7YplnYdkg642kQmeDhbGF0VyVyft2BQINKLLQu9It8ytq5mzmDtBRUdg0nsfTKZSeo IrvIWkyLOXtftBa3cdoe2HMUVBHOMCtaDE3Z9T+G4kBlxghM6YiQdFOg2mQuCTd6rF+b LRNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-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=kz2ouu5rgB7holvcpQKvUKb3i8IsL+WyZDlVQd5W+xw=; b=X1UqkJUzlEJvSOieueNnkz3NLVfvh8rHBaVlv9zeUic85/dq+E3m83BOC61W/DXaMY 3wnnHDyWa5/gXQ4fUkq9krs9oMye9k0P99fDz3jS7kx2skNoqfyGx0Nd7cPq0x/d/ND2 BBNS0YrcgxtqaDSAWsHOlw98ezvgKbHmL1Zx7Xffu0dc1WkziQbTCSSD4/dLcj/kUDRt Kf6K4V/1RTKxbiSt5bEYa/Wi677WRnmrJpjFAGIzRCxd3jBKv5oPkwRwymmCWOb1w77v 7OgRpfR846u4yyHX10utclfhUGa0KxvtGLMe4pGaQJkzhUdV9BwCslteT1HSQFQjP6XR F2Bg== X-Gm-Message-State: AN3rC/4nYsGyrogGaowN9HDaMerV7s0JG2B7Btm9YlIwHI/JcU5jT+V/ lVUswVz4I9ieqg== X-Received: by 10.46.22.84 with SMTP id 20mr4344995ljw.9.1493859257130; Wed, 03 May 2017 17:54:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.195.137 with SMTP id t131ls71549wmf.0.canary-gmail; Wed, 03 May 2017 17:54:15 -0700 (PDT) X-Received: by 10.28.57.6 with SMTP id g6mr994792wma.112.1493859255587; Wed, 03 May 2017 17:54:15 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr. [80.12.242.124]) by mx.google.com with ESMTPS id k28si553383wre.110.2017.05.03.17.54.15 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 03 May 2017 17:54:15 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.124; Original-Received: from imac-de-vicente-botet-escriba.home ([2.10.138.79]) by mwinf5d37 with ME id G0uE1v00K1ixzca030uEbP; Thu, 04 May 2017 02:54:15 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 04 May 2017 02:54:15 +0200 X-ME-IP: 2.10.138.79 In-Reply-To: <13f995f2-f92c-4a73-a8d5-b7dea6395d20@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:32297 Archived-At: This is a multi-part message in MIME format. --------------0322D65C87AD79B2B0125222 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 03/05/2017 =C3=A0 15:12, Barry Revzin a =C3=A9crit : > > That's a fair analogy; but I still can't picture what kind of core > language feature would help here. With lambdas it was pretty > obvious what the core feature was; the only bikeshedding was over > the spelling of []. With customization points, it's not real clear > /what/ we're trying to spell in the first place. A new call > syntax? A new way of doing name lookup? A new way of defining > functions? > > > Reaching back into the archives, the original range-based for loop=20 > proposal used concepts as customization points:=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2778.htm,=20 > which would invoke std::Range<_RangeT>::begin(__range) and=20 > std::Range<_RangeT>::end(__range). > Thanks for adding this old link. The calling interface should be even=20 more simple std2::range::begin(aRange) and std2::range::end(aRange) but=20 not simpler: std2::begin(aRange) and std2::end(aRange). IMO, the std2 customization mechanism as proposed for the Range TS=20 doesn't scale for the C++ standard library and the approach cannot be=20 used by the users to define his own customization points. The last could=20 be seen as not a problem for the standard C++, but people must solve=20 concrete problems and they copy the C++ library design as it should be=20 the correct one, but they cannot in this case. See for example the=20 customization mechanism of Boost.Hana and many other generic libraries.=20 If they use ADL as customization point, they can not support C++=20 standard library types. We will see more a more concepts very soon. In the same way we associate=20 a member function to a class, we should associate a customization point=20 to a concept and name it. There shouldn't be a confusion of which=20 customization point belongs to what concept. It is not the same=20 product_type::get than sum_type::get, container::size than memory::size.=20 begin/end is not something limited to ranges. When I say name it I mean=20 that the user must name the concept and the function name when she want=20 to call it and that the customization is done explicitly using this=20 concept name as well. This is not the design used in on the C++ standard=20 up to C++17 and will not change for C++20 with the current direction. We would need more a more customization points if we continue to do=20 generic programming and not only on the C++ standard library. Having all=20 these customization points in a flat namespace don't scale, the=20 customization points become pseudo keywords. We need to scope them. We=20 have namespaces to manage with scope, and the standard library is not=20 using them (the exceptions of chrono and filesystem are domain=20 namespaces which of course is a very good use of namespaces). I expected=20 to have a std2::ranges namespace in the future STD2 to signal that=20 anything there was talking about customization points of the the Range=20 concept and the algorithms that work with this concept. Instead, IIUC we=20 will have again a flat std2 namespace without structure. I know that=20 this will make the names longer, but we have other C++ features that=20 help us, as namespace aliases. Language that don't have namespaces rely=20 on prefixes to ensure a unique meaning for a customization point. C++=20 is more powerful and we should use this power for the standard library. I don't see the advantage of having implicit mappings that are based on=20 syntactical vraisemblance. Why a class defining begin() and end()=20 function members should become a Range if the functions don't support=20 the Range semantics. While sometimes it is possible to ensure almost all=20 the semantic concerns others it isn't so easy. At the end a syntactical=20 mapping has more liabilities than advantages as most of the short term=20 solutions. I know that we want backward compatibility and any alternative=20 customization approach needs to address it. This doesn't mean that we=20 should base our future customization strategy on an approach ADL that=20 has a lot of problems, see [N1691]. I agree that we need a language feature to define customization points=20 and a way to customize them. Other languages have already do that with=20 success. C++ is a complex language and we don't want to add anything=20 that make it even more complex. I believe however that we really need to=20 solve this problem at the languages level. IMHO, C++0x addressed in part=20 this problematic but the C++ standard abandoned this direction and=20 people as Bjarne Stroustrup and many others don't want to consider any=20 proposal that has an explicit concept/customization points mapping. This=20 means that people are trying to solve the problem at the library level.=20 I believe that the proposed std2 customization mechanism has his merits=20 on the continuation of this direction. The approach solves already some=20 important problems, but the solution doesn't takes in account the=20 problems addressed in [N1691] and is more complex that the lambda user=20 is able to design. As Bjarne Stroustrup says, "Make simple thing simpler". Sorry, but I don't have a language proposal. In the mean time I use an=20 alternative customization point mechanism (close to the one of=20 Boost.Hana) that is explicit in the calling side and explicit in the=20 customization side, but the customization solution is a little bit=20 cumbersome. I use it on some of my proposal as Nullable, Factories,=20 Product Type. I'm using the same approach also for other on going=20 proposal I'm working on, as e.g. for Sum Types, Ordinal types, Functors=20 or Monads. These proposals don't propose function object to represent=20 the user interface but this could be considered. IMHO, providing=20 function objects is orthogonal to the customization point approach and=20 the fact that the current STD2 approach requires the use of function=20 objects shouldn't be considered as a goal. As others have noted we have=20 some proposals on overloads sets that would make it very easy to provide=20 a function object associated to an overload set. The current customization points could be adapted to this explicit=20 approach while preserving backward compatibility, as e.g. for Swappable,=20 Hashable and Range. I don't see these proposals as a final solution and=20 I hope these proposals could inspire some language solution(s) (some=20 kind of explicit namespace, partial template class specialization from=20 unrelated namespaces, traits, ...) or at least a better library solution. Vicente [N1691] Explicit Namespaces http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html --=20 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 e= mail 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/3f13697d-a5d6-d802-68b6-291c79f0b041%40wanadoo.f= r. --------------0322D65C87AD79B2B0125222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 03/05/2017 =C3=A0 15:12, Barry Revzin= a =C3=A9crit=C2=A0:
That's a fair analogy; but I still can't picture what kind of core language feature would help here.=C2=A0 With lambdas it was pretty obvious what the core feature was; the only bikeshedding was over the spelling of []. With customization points, it's not real clear what we're trying to spell in the first place.=C2=A0 A new call syntax?=C2=A0 A new way of doing name lookup?=C2=A0 A new w= ay of defining functions?


Reaching back into the archives, the original range-based for loop proposal used concepts as customization points: http://www.open-std.org/jtc1/s= c22/wg21/docs/papers/2008/n2778.htm, which would invoke=C2=A0std::Range<_RangeT>::be= gin(__range) and=C2=A0std::Range<_RangeT>::en= d(__range).=C2=A0

Thanks for adding this old link. The calling interface should be even more simple=C2=A0 std2::range::begin(aRange) and std2::range::end(aRange) but not simpler: std2::begin(aRange) and std2::end(aRange).

IMO, the std2 customization mechanism as proposed for the Range TS doesn't scale for the C++ standard library and the approach cannot be used by the users to define his own customization points. The last could be seen as not a problem for the standard C++, but people must solve concrete problems and they copy the C++ library design as it should be the correct one, but they cannot in this case.=C2=A0 See f= or example the customization mechanism of Boost.Hana and many other generic libraries. If they use ADL as customization point, they can not support C++ standard library types.

We will see more a more concepts very soon. In the same way we associate a member function to a class, we should associate a customization point to a concept and name it. There shouldn't be a confusion of which customization point belongs to what concept. It is not the same product_type::get than sum_type::get, container::size than memory::size. begin/end is not something limited to ranges.=C2=A0 When I say name it I mean that the user must name the concept and the function name when she want to call it and that the customization is done explicitly using this concept name as well. This is not the design used in on the C++ standard up to C++17 and will not change for C++20 with the current direction.

We would need more a more customization points if we continue to do generic programming and not only on the C++ standard library. Having all these customization points in a flat namespace don't scale, the customization points become pseudo keywords. We need to scope them. We have namespaces to manage with scope, and the standard library is not using them (the exceptions of chrono and filesystem are domain namespaces which of course is a very good use of namespaces). I expected to have a std2::ranges namespace in the future STD2 to signal that anything there was talking about customization points of the the Range concept and the algorithms that work with this concept. Instead, IIUC we will have again a flat std2 namespace without structure. I know that this will make the names longer, but we have other C++ features that help us, as namespace aliases. Language that don't have namespaces rely on prefixes to ensure a unique meaning for a customization point.=C2=A0 C++ is more powerful an= d we should use this power for the standard library.

I don't see the advantage of having implicit mappings that are based on syntactical vraisemblance. Why a class defining begin() and end() function members should become a Range if the functions don't support the Range semantics. While sometimes it is possible to ensure almost all the semantic concerns others it isn't so easy. At the end a syntactical mapping has more liabilities than advantages as most of the short term solutions.

I know that we want backward compatibility and any alternative customization approach needs to address it. This doesn't mean that we should base our future customization strategy on an approach ADL that has a lot of problems, see [N1691].

I agree that we need a language feature to define customization points and a way to customize them. Other languages have already do that with success. C++ is a complex language and we don't want to add anything that make it even more complex. I believe however that we really need to solve this problem at the languages level. IMHO, C++0x addressed in part this problematic but the C++ standard abandoned this direction and people as Bjarne Stroustrup and many others don't want to consider any proposal that has an explicit concept/customization points mapping. This means that people are trying to solve the problem at the library level. I believe that the proposed std2 customization mechanism has his merits on the continuation of this direction. The approach solves already some important problems, but the solution doesn't takes in account the problems addressed in [N1691] and is more complex that the lambda user is able to design. As Bjarne Stroustrup says, "Make simple thing simpler".

Sorry, but I don't have a language proposal. In the mean time I use an alternative customization point mechanism (close to the one of Boost.Hana) that is explicit in the calling side and explicit in the customization side, but the customization solution is a little bit cumbersome. I use it on some of my proposal as Nullable, Factories, Product Type. I'm using the same approach also for other on going proposal I'm working on, as e.g. for Sum Types, Ordinal types, Functors or Monads. These proposals don't propose function object to represent the user interface but this could be considered. IMHO, providing function objects is orthogonal to the customization point approach and the fact that the current STD2 approach requires the use of function objects shouldn't be considered as a goal. As others have noted we have some proposals on overloads sets that would make it very easy to provide a function object associated to an overload set.

The current customization points could be adapted to this explicit approach while preserving backward compatibility, as e.g. for Swappable, Hashable and Range. I don't see these proposals as a final solution and I hope these proposals could inspire some language solution(s) (some kind of explicit namespace, partial template class specialization from unrelated namespaces, traits, ...) or at least a better library solution.

Vicente

[N1691] Explicit Namespaces
http://www.open-std.org/jtc1/sc22/w= g21/docs/papers/2004/n1691.html


--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/3f13697d-a5d6-d802-68b6-291c79f0b041= %40wanadoo.fr.
--------------0322D65C87AD79B2B0125222-- .