220 32320 <68381f91-4180-429c-8f52-de00bd725c60@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Solving the std::swap embarrassment*? Date: Fri, 5 May 2017 13:40:43 -0700 (PDT) Lines: 340 Approved: news@gmane.org Message-ID: <68381f91-4180-429c-8f52-de00bd725c60@isocpp.org> 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> <3f13697d-a5d6-d802-68b6-291c79f0b041@wanadoo.fr> <75ea01c3-e829-4ba6-9311-189748f73354@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_936_621799994.1494016843780" X-Trace: blaine.gmane.org 1494016845 28784 195.159.176.226 (5 May 2017 20:40:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 May 2017 20:40:45 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDELF54RTIGRBTGGWPEAKGQES4AW3JA@isocpp.org Fri May 05 22:40:40 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6k1n-0007OU-UD for gclcip-std-proposals@m.gmane.org; Fri, 05 May 2017 22:40:40 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id w11sf19940423itf.13 for ; Fri, 05 May 2017 13:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Rhvut5zMJ8gYFVO5bz+oAWG+7FY68mJm4tnLsIQxFEo=; b=cYf4oudT/N4ptjUkkVrxlrQPrV5nKYYIf8zCcYGKRM7FEx8m+PvXEYUL+9yKRzeEwB 9OHkP/7nO14FiRdUIuDKojpHrF9PMf4v9cFHF1LPVW7UVOI/ZI2QqP51K1EUyctkOOmz jKjWAGvJ2Ce8OevP6cC/S5l6MmxCub8NKYNtRsx8WOjIPdxIc6CmuHXlKT4rk3ANvDCU A3/yC6ZoktEu/YlIQoVmnJ8nMxsI0FAx6DLC6Nh5rMqoTyRP8h1EPs/PLR+8lWQTRD3H 0NMhSvkninG4N+c0LfVRseLaEbc0jIrAy8FUD7uRH1clIebsRoW6YfkBUzo8BnLw0UoR gLvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Rhvut5zMJ8gYFVO5bz+oAWG+7FY68mJm4tnLsIQxFEo=; b=HfgZyib1ikO8ufgmX2CKDhUKSbVdKG208thrre/Fa/xDNkQUU9OSyKQjxtKH4+Xnj/ KQj8ry3uSHngvsKqMANey0Vxc9vdd3Iih90KEeNgZAMxyd0WAqdJ5q584+llp3nX5fda IYOJcBf9cDD3TVT+Yjz3sD8Nk75t+C1QPgp29ABNa6w8EqbsmQEWpErbnvq64Msh3ikz kiikhbvNdBNMev2q5frClSQx1iF8OaVRjc6FucfnaiJfOB4vgzQbdH5h83vhljWD4O8O po9CLGG61nSiFjvq5ga6vwemXzYWcffVRUEvO+lBHWw0axjgWbFY+wmvJtkEgb9EoSc7 5tTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Rhvut5zMJ8gYFVO5bz+oAWG+7FY68mJm4tnLsIQxFEo=; b=BEKHHN3wI+U+4m4PK0sb4MOLNPZv14XZpIvju8n1UvPITWLkIyrYhj6fyWYgoWCsXi fMRH/B2cQqfmI/Zxqgswo8YgkP7GKuc/p9ggajzL8Lifo6Dvzz12mvpxb71bHyqjtwLO 6jTtFlDzpt7m0tAS9P4mdRIvufoMTn3fi77W/BMn1HutsHGAAABip6g1vvVahrFppoYj ih45w2/1rGmjBQNhpaO/QRaXhHu7HCBYezFH79qoAptB9mzBSGpJls3ANnBg3dmKWvEM UZwEC8nY9Do1uygmK9Gz3aY59T3noM2ccw7OuHiN31sqfepsi4d8NfrISaOW089i9lKd 9SBA== X-Gm-Message-State: AN3rC/6Rex6AhWhbUADE75m79g9dyv1QExUMH9Ru/7TBFmOa434wv1y1 9AV2vT53n2HJiQ== X-Received: by 10.107.51.12 with SMTP id z12mr22682009ioz.57.1494016845233; Fri, 05 May 2017 13:40:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.90 with SMTP id r26ls4789682otd.0.gmail; Fri, 05 May 2017 13:40:44 -0700 (PDT) X-Received: by 10.157.14.147 with SMTP id 19mr1026511otj.1.1494016844472; Fri, 05 May 2017 13:40:44 -0700 (PDT) In-Reply-To: <75ea01c3-e829-4ba6-9311-189748f73354@isocpp.org> X-Original-Sender: fmatthew5876@gmail.com 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:32320 Archived-At: ------=_Part_936_621799994.1494016843780 Content-Type: multipart/alternative; boundary="----=_Part_937_1688239810.1494016843780" ------=_Part_937_1688239810.1494016843780 Content-Type: text/plain; charset=UTF-8 On Friday, May 5, 2017 at 2:58:13 PM UTC-5, Nicol Bolas wrote: > > On Friday, May 5, 2017 at 2:29:03 PM UTC-4, Matthew Fioravante wrote: >> >> On Friday, May 5, 2017 at 1:03:10 PM UTC-5, Nicol Bolas wrote: >>> >>> Because it would be a backwards-incompatible change. >>> >> >> C++ has broken backwards compatibility before. Right now if you call >> std::swap() on your object, unless its in std you'll get a default move >> based swap operation. Suppose that was all of the sudden silently changed >> to actually call your type's swap() operation if it has one. How bad would >> that be? How much code would it break? >> >> I consider swap() special in the same vein as move and copy. We've added >> rules to change how those are called/elided in the past knowing it could >> break code. If you write a swap() its suppose to do swapping, if it does >> something else you get what you deserve. "Optimizing" std::swap() to call >> your types custom swap if it has one does not sound like a bad thing to me. >> >> The fact that essential library primitives like swap() and begin() >> require expert level knowledge to use correctly is a complete and utter >> failure.* Really, its just ****ing stupid.* ADL is not the proper tool >> for this. I'd argue ADL is only really useful for operator overloading. >> Unless you put swap(), begin(), etc.. to the global :: namespace, ADL will >> never work. That's a non-starter too as third party libraries wanting to >> define "customization points" such as begin() certainly cannot just put >> stuff in the global namespace. >> >> With have virtual functions for runtime dispatch, and this broken crap >> interface for compile time dispatch. This is a serious bug that needs to be >> fixed. >> > > I don't disagree on the importance of customization points. I don't > disagree with the need to have them work. > > That alone however *cannot* justify doing it in a backwards-incompatible > way. > > It also wouldn't help users create similar interfaces that have similar >>> behavior. >>> >> >> That's a secondary concern. >> > > I strongly disagree. It's like saying that we need to have ranges in the > standard library, but it's a secondary concern to provide tools to help > people write standard library compatible ranges. What good is it to have > standard idioms if writing idiom-compatible constructs is so complex/arcane > that users can not reasonably be expected to define them on their own? > > Writing a standard library compatible range should not be hard. Writing a > standard library compatible customization point should also not be hard. > This should be a primary concern of any solution to this problem. Once we > standardize the concept of "customization point", people will and should > want to do it in a way that is compatible with the standard library. If we > make that simple, then we allow them to do so. > > If we make the idiom complex or arcane, all we do is create dozens of > headaches down the road. > So then add the tools to help create these things. I never said we shouldn't. However when making engineering trade-offs in the interface, its better to design something optimized for the common case (calling a customization point) over the rare case (writing the default dispatch driver for a customization point library). > > >> If I want to write foo::fooify() customization point in libfoo, I can >> lookup a tutorial to get all of the dispatching correct. I only need to do >> this once for all of the thousands if not millions of times my users will >> just need to say foo::fooify(fooable_thing);. If I'm writing my own >> customization points, I'm already an expert C++ developer. >> > > That kind of thinking is what gets us `std::enable_if`. "If I want to do > some SFINAE-style stuff, then I'm already an expert C++ developer". > I don't agree with this comparison. Hacking overload resolution with enable_if is something we do way more often than creating new customization points. The use case here is not "I want to do SFINAE stuff" (expert only implementation specific gibberish), its "I want write a math function which only operates on any kind of `real number' type" (basic core idea). Before we go ahead and add language features, ugly less invasive things like this are a good start to get experience. Everybody hates enable_if for good reason but before concepts that's all we had to solve a real need. The standard library 10 years from now is not going to be any worse off for the existence of an old enable_if template now collecting dust unused in the new conceptified regime. > Utter nonsense. By adding appropriate things to the language, we give > novices the power to do the things that experts do. We take arcane idioms > and bring them to the masses. > > When we get concepts, you'll see the number of people using SFINAE > increase dramatically. Why? Because it makes it a real part of the > language, not some arcane hack. Users have needs that SFINAE could solve, > but they don't use it because it's needlessly difficult and > over-complicated. The same goes here. Creating a customization points > should not be something that requires being an expert C++ developer. Users > want to be able to do these things, but as of yet, there is no good, simple > solution for it. > > Furthermore, we could also consider adding helper utilities for this in >> the standard library, even if they have to be macros. >> > > Yes, don't bother with a nice, neat language feature. It's much better to > do this sort of stuff as a macro. > Ok so invent a new language feature then. I'd be plenty happy with that too. I don't think you can do this with templates as they are currently which is why a macro was suggested. A language feature would need to be more general purpose. I'm not sure it would ever fly to create a core language feature solely for the purpose of writing customization points. I'm not at all married to using std::swap() to solve the problem. If someone has a better solution I'll be the first one to jump on board. Whatever the solution is, this using std::swap; swap(); nonsense has got to go. It also needs to be solved not just for swap(), but for all customization points including begin(), end(), cbegin(), cend(), rbegin(), rend(), size(), data(), etc.. As an added bonus, this should also mean we can all stop doing the brainless and bug friendly work of writing cbegin(), cend(), rbegin(), rend(), rbegin() const, rend() const, crbegin(), crend() for all of our custom container classes. Instead just relying on the default adapters generated by the std:: default versions adapting begin(), begin() const, end(), and end() const. Lets not also forget we have concepts on the way. Once concepts are out in the wild this ADL problem is going to become a much bigger issue fast. Its was one of the main use cases driving unified function call syntax. Do we want to wait until the bug reports and complaints after concepts or should we not try to attack this issue now? If I want to make an Iterable concept, I'd like to just say that it begin(x) and end(x) are valid expressions which return Iterator concepts. Why the hell do I need to deal with these using declaration gymnastics? How do I carefully add them without polluting the entire scope? I still haven't review the concepts proposal in detail. Can I even put a using declaration inside a concept expression? For homework, try to implement the following from scratch. Do not cheat with type_traits, concepts, or any other std:: machinery that already solves the problem. Do not pollute the enclosing scope with using declarations. * Given a type T, write a noexcept() expression which is true if the swap() expression for an object of type T would be noexcept. * Given a type T, write a decltype() expression to get the type resulting from a begin() expression called on an object of type T. -- 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/68381f91-4180-429c-8f52-de00bd725c60%40isocpp.org. ------=_Part_937_1688239810.1494016843780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, May 5, 2017 at 2:58:13 PM UTC-5, Nicol = Bolas wrote:
O= n Friday, May 5, 2017 at 2:29:03 PM UTC-4, Matthew Fioravante wrote:
On Friday, May 5, 2017 at= 1:03:10 PM UTC-5, Nicol Bolas wrote:
Because it would be a backwards-incompatible change= ..

C++ has broken backwards comp= atibility before. Right now if you call std::swap() on your object, unless = its in std you'll get a default move based swap operation. Suppose that= was all of the sudden silently changed to actually call your type's sw= ap() operation if it has one. How bad would that be? How much code would it= break?

I consider swap() special in the same vein= as move and copy. We've added rules to change how those are called/eli= ded in the past knowing it could break code. If you write a swap() its supp= ose to do swapping, if it does something else you get what you deserve. &qu= ot;Optimizing" std::swap() to call your types custom swap if it has on= e does not sound like a bad thing to me.

The fact = that essential library primitives like swap() and begin() require expert le= vel knowledge to use correctly is a complete and utter failure. Really, = its just ****ing stupid. ADL is not the proper tool for this. I'd a= rgue ADL is only really useful for operator overloading. Unless you put swa= p(), begin(), etc.. to the global :: namespace, ADL will never work. That&#= 39;s a non-starter too as third party libraries wanting to define "cus= tomization points" such as begin() certainly cannot just put stuff in = the global namespace.

With have virtual functions = for runtime dispatch, and this broken crap interface for compile time dispa= tch. This is a serious bug that needs to be fixed.
=

I don't disagree on the importance of customization points. I = don't disagree with the need to have them work.

That alone howev= er cannot justify doing it in a backwards-incompatible way.

<= /div>
It also wouldn't help = users create similar interfaces that have similar behavior.

That's a secondary concern.

I strongly disagree. It's like saying that we n= eed to have ranges in the standard library, but it's a secondary concer= n to provide tools to help people write standard library compatible ranges.= What good is it to have standard idioms if writing idiom-compatible constr= ucts is so complex/arcane that users can not reasonably be expected to defi= ne them on their own?

Writing a standard library compatible range sh= ould not be hard. Writing a standard library compatible customization point= should also not be hard. This should be a primary concern of any solution = to this problem. Once we standardize the concept of "customization poi= nt", people will and should want to do it in a way that is compatible = with the standard library. If we make that simple, then we allow them to do= so.

If we make the idiom complex or arcane, all we do is create doz= ens of headaches down the road.

=
So then add the tools to help create these things. I never said we sho= uldn't. However when making engineering trade-offs in the interface, it= s better to design something optimized for the common case (calling a custo= mization point) over the rare case (writing the default dispatch driver for= a customization point library).
=C2=A0
=C2=A0
If I want to write foo::fooif= y() customization point in libfoo, I can lookup a tutorial to get all of th= e dispatching correct. I only need to do this once for all of the thousands= if not millions of times my users will just need to say foo::fooify(fooabl= e_thing);. If I'm writing my own customization points, I'm already = an expert C++ developer.

That kind of thin= king is what gets us `std::enable_if`. "If I want to do some SFINAE-st= yle stuff, then I'm already an expert C++ developer".

I don't agree with this comparison.= Hacking overload resolution with enable_if is something we do way more oft= en than creating new customization points.

The use= case here is not "I want to do SFINAE stuff" (expert only implem= entation specific gibberish), its "I want write a math function which = only operates on any kind of `real number' type" (basic core idea)= ..

Before we go ahead and add language features, ugly less inv= asive things like this are a good start to get experience. Everybody hates = enable_if for good reason but before concepts that's all we had to solv= e a real need. The standard library 10 years from now is not going to be an= y worse off for the existence of an old enable_if template now collecting d= ust unused in the new conceptified regime.



U= tter nonsense. By adding appropriate things to the language, we give novice= s the power to do the things that experts do. We take arcane idioms and bri= ng them to the masses.

When we get concepts, you'll see the numb= er of people using SFINAE increase dramatically. Why? Because it makes it a= real part of the language, not some arcane hack. Users have needs that SFI= NAE could solve, but they don't use it because it's needlessly diff= icult and over-complicated. The same goes here. Creating a customization po= ints should not be something that requires being an expert C++ developer. U= sers want to be able to do these things, but as of yet, there is no good, s= imple solution for it.

Furthermore, we could also consider adding helper ut= ilities for this in the standard library, even if they have to be macros. <= br>

Yes, don't bother with a nice, nea= t language feature. It's much better to do this sort of stuff as a macr= o.

Ok so invent a new lang= uage feature then. I'd be plenty happy with that too. I don't think= you can do this with templates as they are currently which is why a macro = was suggested. A language feature would need to be more general purpose. I&= #39;m not sure it would ever fly to create a core language feature solely f= or the purpose of writing customization points.

I&= #39;m not at all married to using std::swap() to solve the problem. If some= one has a better solution I'll be the first one to jump on board. Whate= ver the solution is, this using std::swap; swap(); nonsense has got to go.<= /div>

It also needs to be solved not just for swap(), bu= t for all customization points including begin(), end(), cbegin(), cend(), = rbegin(), rend(), size(), data(), etc.. As an added bonus, this should also= mean we can all stop doing the brainless and bug friendly work of writing = cbegin(), cend(), rbegin(), rend(), rbegin() const, rend() const, crbegin()= , crend() for all of our custom container classes. Instead just relying on = the default adapters generated by the std:: default versions adapting begin= (), begin() const, end(), and end() const.



Lets not also forget we have concepts on the way. Once co= ncepts are out in the wild this ADL problem is going to become a much bigge= r issue fast. Its was one of the main use cases driving unified function ca= ll syntax. Do we want to wait until the bug reports and complaints after co= ncepts or should we not try to attack this issue now?

If= I want to make an Iterable concept, I'd like to just say that it begin= (x) and end(x) are valid expressions which return Iterator concepts. Why th= e hell do I need to deal with these using declaration gymnastics? How do I = carefully add them without polluting the entire scope? I still haven't = review the concepts proposal in detail. Can I even put a using declaration = inside a concept expression?

For homework, try to = implement the following from scratch. Do not cheat with type_traits, concep= ts, or any other std:: machinery that already solves the problem. Do not po= llute the enclosing scope with using declarations.

* Given a type T, write a noexcept() expression which is true if the swap(= ) expression for an object of type T would be noexcept.
* Given a= type T, write a decltype() expression to get the type resulting from a beg= in() expression called on an object of type T.

--
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/68381f91-4180-429c-8f52-de00bd725c60= %40isocpp.org.
------=_Part_937_1688239810.1494016843780-- ------=_Part_936_621799994.1494016843780-- .