220 41089 <947f5ce9-161f-4c16-b173-9b36476a137e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: The PhD Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: d1193 (Unpublished) - Explicit Return Types for (Implicit) Conversions Date: Mon, 26 Nov 2018 21:15:35 -0800 (PST) Lines: 345 Approved: news@gmane.org Message-ID: <947f5ce9-161f-4c16-b173-9b36476a137e@isocpp.org> References: <331d08dc-54ad-4681-abe8-986b66bf354a@isocpp.org> <6d5ed13d-c31a-4218-88b0-e0dd4bef3f72@isocpp.org> <55f4ba50-6b86-4f65-858a-754c347cdeb9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1752_122634472.1543295735759" X-Trace: blaine.gmane.org 1543295612 27878 195.159.176.226 (27 Nov 2018 05:13:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 05:13:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDN2PNGWZQEBB6FF6PPQKGQERP7HNCY@isocpp.org Tue Nov 27 06:13:28 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f199.google.com ([209.85.219.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRVge-00078P-5u for gclcip-std-proposals@m.gmane.org; Tue, 27 Nov 2018 06:13:28 +0100 Original-Received: by mail-yb1-f199.google.com with SMTP id o131-v6sf3204814yba.17 for ; Mon, 26 Nov 2018 21:15:38 -0800 (PST) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=EwwCQlKmiqA49+PA7at36P7EKxCvPBNrN2qzdR6MjsI=; b=TfSaHQieQgiP8NhOpfFfl5TyE3tkn2pmWEZnQd1HcADJppgdZ1Joa4w3wek6cuPrV7 ePeHZ0VMN8cO5OQCYTT+qVnHwO644obhCHccVZIBf6yfHz4fhqd5EsuaTeWt7hM7Cmkt 7KVRxmhXiNBWDyG6TnJ69NUQ0+Bgje2f9O2lSY5o/WA7Z/gHTH30z7mqY67x0q8VI4nJ LlN8Rkje2aq6Hc9Xjbw+B0kuYleQFxZ/dbrz2wV+k9IrLA87IhFx1ccNozd0cKYH5O92 OA0Ke0gpBpWNZ8AG5BO65o/np/x3NB2XyXlXjRPyC6TbOB0qCdHQbMvUQjrNnZRSfWpo yG8w== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=EwwCQlKmiqA49+PA7at36P7EKxCvPBNrN2qzdR6MjsI=; b=cWIE1tjEkEBCcsek//6d7HyjerBzJw3VSVTvCCpI0v/+Xhyza2/zVOzgGd6k+8KWLq ZFzvvl6g96JXMhXQrXXG00Y8RIRXPP5ws/Re9SxChPzbew0hIUKY0j1WeKvOmgRjGxuC 8Dktt7e9VPRuQMmc9+z34wlvkD7U1ReLZOCKYKiGzajJ9mDDGlxdi4AIQQoUtb0cOuJq 9T+9Eupeu6hEsXJHef/rRfkqTVKv9QVt8GQtbK4MP1KL0nbU744p7Rdv7qYVU7zAY1JR 9PNHjGzsjtWzZw89f2tgoacdrSIN3TuQGUhEU8a9qrk0wlMxyYnpHUHkXotUZGWWF3Ns zhpg== 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=EwwCQlKmiqA49+PA7at36P7EKxCvPBNrN2qzdR6MjsI=; b=TV9VrCwvD6NMTxMCFazbfdbMK+/avwRCzL0CjRaIrZIa1uumB2EFKy8L9Zbjz+Xvli FZ1iQRHm74vmtIETjiDK7ccY/ZDtTC/YxcmzA2b6G0KN8DXu60buIFCC2pjouj28FEXj mAhkkLMoySEt8a6g1deGwxL16K/SeeiOSCD0Iz3p6DedjDgTBAKLSm1TSX3vFO7q2q6K ohMpsOs2zBxOm4obgSC5yyTr3uDUzCnCG/8E+jZCCR3fS5pasJ6h1NPRtyo+vvqq9a94 HaJJYCmmFl5T+ZBRnk2myrbbQPchXgZe4d+Ok0+rSUJ3y6/mTwOKPChXkLRy/wUhV2Y5 U1fA== X-Gm-Message-State: AA+aEWbWphJmFw8OjtEbZbSzEzSiz/GzUEDsw274KfDayu5EtPfnXORz /C7wne7fHUqu38zaE5w+QlED7A== X-Google-Smtp-Source: AFSGD/WKWV3k4i3oNEIkiZnzW6vLdLTgVtJyzK/+vsO/o+VqHUBqj8/+4SxTnSjO0lqS6Tz8i6HzJw== X-Received: by 2002:a25:d007:: with SMTP id h7-v6mr9397340ybg.8.1543295738253; Mon, 26 Nov 2018 21:15:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:d449:: with SMTP id w70ls8628314ywd.6.gmail; Mon, 26 Nov 2018 21:15:36 -0800 (PST) X-Received: by 2002:a81:5bc6:: with SMTP id p189-v6mr379288ywb.3.1543295736407; Mon, 26 Nov 2018 21:15:36 -0800 (PST) In-Reply-To: X-Original-Sender: phdofthehouse@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:41089 Archived-At: ------=_Part_1752_122634472.1543295735759 Content-Type: multipart/alternative; boundary="----=_Part_1753_2046607187.1543295735760" ------=_Part_1753_2046607187.1543295735760 Content-Type: text/plain; charset="UTF-8" Richard Smith: > This is a special case of a more general feature: the ability to *compute* the type of a function template specialization from its arguments / deduction context rather than merely *deducing* it. And we already have a mechanism for that in another situation -- deduction guides. They're currently limited to class templates, but the original problem they were designed to solve was actually controlling function template deduction. Conversions are a special case of a more general feature: to me, it made more sense to give them full access to all the tools we have with regular functions today. We can compute types using trailing return types and decltype() and similar. As I understand it, deduction guides work in the place where a return type cannot be specified and also because the grammar of constructor definitions/declarations cannot be changed to support what deduction guides offer without introducing some very interesting corner cases. This does make it seem ideal for conversion operators (a function that cannot specify its own return type properly, just like constructors), but there's no actual grammatical reason for the restriction we have now: removing the restriction that the decl-specifier-seq of the conversion function must not contain a type is a much simpler fix and requires much less typing than making deduction guides apply to conversion functions. The reason (or did I miss something?) CTAD does not apply to things in general to become all-purpose deduction guides is because they are A) predicated on the idea that the entity must be a template, which does not always have to be the case and B) are no more powerful at type computation than trailing returns and decltype today? (I am unsure: people are doing things like writing parsers in CTAD -- https://twitter.com/hankadusikova/status/1045470553069375488). Jake Arkinstall: > If a language/library has a type that is represented in some form, then offer a conversion to that type, rather than masquerading it as another type that it is not. Or, more appropriately, give them a *strong* type with well defined conversions and be done with it. Don't abuse a conversion to int if int has nothing to do with it (and I don't care who thinks otherwise - 2.0 will never be an integer) Lua, Javascript, etc. all fundamentally disagree with you. I'm sure if I was starting from scratch I could make the distinction perfect and propagate across all systems, but I can't. There are functions which pull and integer from Lua, so long as the number does not exceed the 53 allowed bits: disabling that just means people have to go around me, rather than through the system, at which point I've failed to make their lives easier, haven't I? > For example, say you have a rectangle that's actually a square, but you don't want to waste time converting it when you want to resize along one dimensions. You could return a square, but that's inefficient. You could return a rectangle, but that might be used for something else. Or you could create a new type that wraps a rectangle, casts to a rectangle and a square (the latter requiring an actual conversion, the former just returning the rectangle held within), clearly identifies itself as a square rectangle, and there's no controversy. Because such a design imposes a knowledge burden on the user. In the case of sol2, having something convert to `int` or `double` is extremely desierable: the user ran a script that performed x = 2. If they have to get it out on the other side with sol::double_wrapper x = virtual_machine["x"];, then I've failed in my design to provide something that matches basic expectation. "More types" is a good solution when you own the application: it's not a good solution when you are in the library because each type needs to be documented and taught. Relying on common, shared, basic primitives and knowledge and making a system that does not require specialist syntax is an enormous design boon. > Would it? Would it really, in the grand scheme of things, be better? I get that this solves one problem, but it introduces new ones in the almost-always-auto era. Sure, but again the S struct was for the simplest possible demonstration. I explain in full the problem in the motivation section without relying on real-world code so that I can prove that the problem exists in general. Furthermore, I don't understand how "auto" factors in here. auto captures the type exactly as it happens, which means there's no conversions to begin with. This is not the case for things that mock up return-value polymorphism: for example, function f = ...; int value0 = f(1); double value1 = f(4.5); std::string value2 = f("foo"); This is possible because of an omni-converting proxy type. I originally attempted to create a member function to do the work and return a strongly-typed value, but `f( 1 );` is not legal on types with `operator()` overloaded. With an omni-converting proxy type returned by something that represents a non-C++ construct (such as a function in a dynamic language VM or a Stored Procedure in a database), I am not given > Sfinae is an inelegant sledgehammer in these situations, true. But is that a symptom of a problem in the language? I'm not convinced. The SFINAE I have presented here is the simplest SFINAE possible to just barely prevent compiler errors because of `std::string` constructors. Full SFINAE to handle, e.g., not wanting to convert to integral types means I would need about 4 more functions and a much longer line of SFINAE, all of which must be mutually exclusive and forces me to pick Value versus Reference for each conversion (but never both: see https://thephd.github.io/vendor/future_cxx/papers/d1193.html#motivation-mutual). This is not "inelegant": it's horrific. If somebody has to maintain this code after I'm gone or done that's a massive burden of proof. Concepts only alleviate this a little bit, and it once more demonstrates that conversion operations are special creatures that have weird rules that do not let the user take full advantage of what regular functions in the language have to offer. The goal is to remove some restrictions to bring them in line with regular functions. mihail: > Yeah, a simplified version of these examples is what people expect to see in the paper. Okay. I thought that the 2 motivation examples were enough to provide the simplest, generic description of the problem, but I will add more in-depth pointers and examples to the paper. Thanks for pointing it out to me. > Will this be possible with your proposal, not the exact example, but do you count converting constructor on the return type as user conversion? It will not be. That is the chaining case (user defined conversion into user defined constructor). For that to work, you would need to specify that the return type is "B" on the conversion (and then trigger it with either an integer cast or a different overload). However, in thinking it over such a restriction might be too strong. It will work with the e.g. tuple example I have, but will not be as flexible in other scenarios. I think Tony is right here in that I should likely treat it like `operator->` and let it chain as many times as necessary, making it simply re-evaluate the suitability of the expression after the cast or required conversion is applied... but that will be more difficult to do. Thankfully, this is still opt-in: even in your example if I were to introduce a looping rule similar to operator->, it would not work because the new rules would only apply when return-type-specifier != conversion-type-id. -- 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/947f5ce9-161f-4c16-b173-9b36476a137e%40isocpp.org. ------=_Part_1753_2046607187.1543295735760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard Smith:
> This is a special case of a more ge= neral feature: the ability to=20 *compute* the type of a function template specialization from its=20 arguments / deduction context rather than merely *deducing* it. And we=20 already have a mechanism for that in another situation -- deduction=20 guides. They're currently limited to class templates, but the original= =20 problem they were designed to solve was actually controlling function=20 template deduction.

Conversions are a special=20 case of a more general feature: to me, it made more sense to give them=20 full access to all the tools we have with regular functions today. We=20 can compute types using trailing return types and decltype() and=20 similar. As I understand it, deduction guides work in the place where a=20 return type cannot be specified and also because the grammar of=20 constructor definitions/declarations cannot be changed to support what=20 deduction guides offer without introducing some very interesting corner=20 cases.

This does make it seem ideal for conversion operators (a=20 function that cannot specify its own return type properly, just like=20 constructors), but there's no actual grammatical reason for the=20 restriction we have now: removing the restriction that the=20 decl-specifier-seq of the conversion function must not contain a type is a much simpler fix and requires much less typing than making deduction=20 guides apply to conversion functions. The reason (or did I miss=20 something?) CTAD does not apply to things in general to become=20 all-purpose deduction guides is because they are A) predicated on the=20 idea that the entity must be a template, which does not always have to=20 be the case and B) are no more powerful at type computation than=20 trailing returns and decltype today? (I am unsure: people are doing=20 things like writing parsers in CTAD -- https://twitter.com/hankadusikova/stat= us/1045470553069375488).

Jake Arkinstall:
> If = a language/library has a type that is represented in some form, then=20 offer a conversion to that type, rather than masquerading it as another=20 type that it is not. Or, more appropriately, give them a=C2=A0strong= =C2=A0type with well defined conversions and be done with it. Don't abuse a=20 conversion to int if int has nothing to do with it (and I don't care wh= o thinks otherwise - 2.0 will never be an integer)

Lua,=20 Javascript, etc. all fundamentally disagree with you. I'm sure if I was= =20 starting from scratch I could make the distinction perfect and propagate across all systems, but I can't. There are functions which pull and=20 integer from Lua, so long as the number does not exceed the 53 allowed=20 bits: disabling that just means people have to go around me, rather than through the system, at which point I've failed to make their lives=20 easier, haven't I?

> For example, say you have a r= ectangle that's actually a square, but you=20 don't want to waste time converting it when you want to resize along on= e dimensions. You could return a square, but that's inefficient. You=20 could return a rectangle, but that might be used for something else. Or=20 you could create a new type that wraps a rectangle, casts to a rectangle and a square (the latter requiring an actual conversion, the former=20 just returning the rectangle held within), clearly identifies itself as a square rectangle, and there's no controversy.

Because such a=20 design imposes a knowledge burden on the user. In the case of sol2,=20 having something convert to `int` or `double` is extremely desierable:=20 the user ran a script that performed=C2=A0 x =3D 2. If they have to get it out on the othe= r side with sol::doubl= e_wrapper<int> x =3D virtual_machine["x"];, then I've failed in my design to provide something that matches basic= =20 expectation. "More types" is a good solution when you own the=20 application: it's not a good solution when you are in the library=20 because each type needs to be documented and taught. Relying on common,=20 shared, basic primitives and knowledge and making a system that does not require specialist syntax is an enormous design boon.

> Would it? Would it really, in the grand scheme of things, be = better? I=20 get that this solves one problem, but it introduces new ones in the=20 almost-always-auto era.

Sure, but again the S struct was for the=20 simplest possible demonstration. I explain in full the problem in the=20 motivation section without relying on real-world code so that I can=20 prove that the problem exists in general. Furthermore, I don't=20 understand how "auto" factors in here. auto captures the type exa= ctly as it happens, which means there's no conversions to begin with. This is= =20 not the case for things that mock up return-value polymorphism: for=20 example,

function f =3D <= /span>...;=
int value0 =3D =C2=A0f(1);
double value1 = =3D =C2=A0= f(<= span style=3D"color: #066;" class=3D"styled-by-prettify">4.5);
std::string value2 =3D =C2=A0f("foo");

This is possible because of an omni-converting proxy type. I originally=20 attempted to create a member function to do the work and return a=20 strongly-typed value, but `f<int>( 1 );` is not legal on types=20 with `operator()` overloaded. With an omni-converting proxy type=20 returned by something that represents a non-C++ construct (such as a=20 function in a dynamic language VM or a Stored Procedure in a database), I am not given

> Sfinae is an inelegant sledgehammer in these situ= ations, true. But is=20 that a symptom of a problem in the language? I'm not convinced.

= The SFINAE I have presented here is the simplest SFINAE possible to just=20 barely prevent compiler errors because of `std::string` constructors.=20 Full SFINAE to handle, e.g., not wanting to convert to integral types=20 means I would need about 4 more functions and a much longer line of=20 SFINAE, all of which must be mutually exclusive and forces me to pick=20 Value versus Reference for each conversion (but never both: see https://thephd.github.io/vendor/future_cxx/papers/d1193.html#motivatio= n-mutual). This is not "inelegant": it's horrific. If somebody has to m= aintain=20 this code after I'm gone or done that's a massive burden of proof.= =20 Concepts only alleviate this a little bit, and it once more demonstrates that conversion operations are special creatures that have weird rules=20 that do not let the user take full advantage of what regular functions=20 in the language have to offer.

The goal is to remove some restrictio= ns to bring them in line with regular functions.


mihail:

> Yeah, a simplified version of these examples i= s what people expect to see in the paper.
Okay. I thought that the 2 motivation examples were enough to provide the=20 simplest, generic description of the problem, but I will add more=20 in-depth pointers and examples to the paper. Thanks for pointing it out=20 to me.

> Will this be possible with your proposal, not the exact = example, but do=20 you count converting constructor on the return type as user conversion?
=
It will not be. That is the chaining case (user defined conversion into=20 user defined constructor). For that to work, you would need to specify=20 that the return type is "B" on the conversion (and then trigger i= t with=20 either an integer cast or a different overload).

However, in=20 thinking it over such a restriction might be too strong. It will work=20 with the e.g. tuple example I have, but will not be as flexible in other scenarios. I think Tony is right here in that I should likely treat it=20 like `operator->` and let it chain as many times as necessary, making it simply re-evaluate the suitability of the expression after the cast=20 or required conversion is applied... but that will be more difficult to=20 do. Thankfully, this is still opt-in: even in your example if I were to=20 introduce a looping rule similar to operator->, it would not work=20 because the new rules would only apply when return-type-specifier !=3D=20 conversion-type-id.

--
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/947f5ce9-161f-4c16-b173-9b36476a137e= %40isocpp.org.
------=_Part_1753_2046607187.1543295735760-- ------=_Part_1752_122634472.1543295735759-- .