220 41088 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: d1193 (Unpublished) - Explicit Return Types for (Implicit) Conversions Date: Tue, 27 Nov 2018 00:03:02 +0000 Lines: 246 Approved: news@gmane.org Message-ID: 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/alternative; boundary="000000000000ed395d057b9a2ca5" X-Trace: blaine.gmane.org 1543276868 12964 195.159.176.226 (27 Nov 2018 00:01:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 00:01:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBQMT6LPQKGQEQYJEIPQ@isocpp.org Tue Nov 27 01:01:04 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it1-f197.google.com ([209.85.166.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRQoK-0003Ge-87 for gclcip-std-proposals@m.gmane.org; Tue, 27 Nov 2018 01:01:04 +0100 Original-Received: by mail-it1-f197.google.com with SMTP id 66-v6sf24897410itz.9 for ; Mon, 26 Nov 2018 16:03:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1543276994; cv=pass; d=google.com; s=arc-20160816; b=BfIVkGcbNe89c4U2l7R8JdCCqjU/QRJceTEjtws8Lk6u9iXC5mojbV9vrponyNj1EO HWlfpeS+Gpo64p1mK+LjIokY5i/un0EakufQSKNz5pSfkfs7PeJTqejOncNAEeDcrKq7 8sFwj+d0tzIKEHADnYb1Yi9mbO7PJAdfzue/updjqKDqFlW3gsOJ687XYyGiMJmKa9qe uSkDnAOG2/c/sdTqXAmv31byshMotqBiqtD+r9HYrkLbYKRvHxBj4e2Mxhiz5LvJHFLd C3wvGZ/q3fFmpj+EYdfHqgtKaS5PeVHW83cJcuuQFDw8bTy/rDJ+4pinTCGKi8otoBuD wy+g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=0h8YPp72ZalWLVo+5dVRt69elLDs4zRX11CaRxmUBSQ=; b=fEpCYNykoNu8a4kYc6AtTe2XUZrwHwWuDM/EXlF+Bk7Jc9KC09pMhVGoZU/frxxu+k LKHuOx9IMb5LH9+jcTBWMjfdx4VmjxN1aFJBv8oTNK6/zsXSzGIFYDW5rThmvFAgTBQ6 QoMU5sylebPQ4HXzTPDec9pR68v21lHXQ4gUKlwRakfEPc/PFEGmucxwX5mzs9Toi3d3 dXqfThriGnZ5dewcYhZI3zRx/iBS4vSDRyERRolWd/0gr60Jrw0E0TR5KigevQcXFfdM rpRvZ2j731p5ThREdcPOlYBIy/VMxucSYBpc9til9qH3INbGimIHeiIQPE9CeKFaiDO5 qHhA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Zxmbug83; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=0h8YPp72ZalWLVo+5dVRt69elLDs4zRX11CaRxmUBSQ=; b=fQ1zBlO6Rbfz5kT7/DvXQL+6VbP8pg0LOYORWTbJSB/r8TLZd+bLqrKlPH5h348IRy V7CBS+ek7nRTpKT13i1aRi+A2+HspvtmeXkmiaiTplPxqQnme3DsNtLJSG7XnP/esdBP RUcsXgugrV9EZcI8Sl2eXLsCKM3V7+FyhzDlONhGKDRPY52DfvO5SeIkg8Pu2s0DwM9i cT5iXOzNaiTwRxWAS8tnCGM3YCHOzKl5HIrPJMcyRB2E1hrJU1zm5YMg5QS/JDMdVPjj to6A0oynJNwei29nqyePjDecNlx/zWlXDtqo2jVyjLFlaTs1H9tFO6DXUrJdAS+M6uDv rKrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject: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=0h8YPp72ZalWLVo+5dVRt69elLDs4zRX11CaRxmUBSQ=; b=UzWoZwgrIuPrZ3ojlgOPe7VIjAry9mjseZ9LVWALCoOxkO+R5Hl7yL89MPFkTJkaCo NGhaT8ovfizGgLRLRto5IhUZMvZLcJz17kIGXl6BDlrRrxRepUVh014n7cJQ9zlGwDvr IXn1F4IGW1P+2LCpvsww8lVvk/+5RutCadWMOxspeagGHpre9Xf3bvQ1CYj7wV3ZejZr 7KD/6MS0NVtpZmXKPDG3m65kFZQejJN0zwz8s+N0RN4auXjdcKRhTR3bg6ilOPBfGxns ujfhwj+edXrjmZgN/leY92vJawzCO1HZH13iHfxwaOnZHZRVKDQQWhvpWLhfAjFRSh5c UyHA== X-Gm-Message-State: AA+aEWbA3zYmvdK5UZYJTIQpgZK7Jayu1+GzXw4ZZ9Tp+sZPZN7LGIvd 4mBKn6keM+OXOC75/hhZnqXgsQ== X-Google-Smtp-Source: AFSGD/U2ANvzvmqnUdugUq2bJrNivCL5W1m29hjTFJvNaMl6z+hOq3uzLGrIJoqhSKQMn4bshkLz3Q== X-Received: by 2002:a5e:d919:: with SMTP id n25-v6mr18575194iop.0.1543276994475; Mon, 26 Nov 2018 16:03:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:5f8b:: with SMTP id r133-v6ls6914791itb.3.canary-gmail; Mon, 26 Nov 2018 16:03:13 -0800 (PST) X-Received: by 2002:a24:db02:: with SMTP id c2mr26903023itg.137.1543276993066; Mon, 26 Nov 2018 16:03:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543276993; cv=none; d=google.com; s=arc-20160816; b=Sh8mlqQ9a9BL8aN+Cwd/i9cpmhYgKpWYiZ21/yLTF/XfI2XuEIUNLQCdT/FrHOw5N9 i1BUE7jM08yAkJ4AGzkeUFip3zFhISAAsHqI+99d6wUOiIOoPqvtfJMPKiLM7I78z+R1 dLm89b9zWkLfUfko8Ll3IEJSqXfHc7HjYg68SXNEOyugpsW634zjbqDGw25+I0ovMvol v4o/aHGmg4bazH7L2xuB33WQfRMcSxCA0hDD4QC8puSd+V5eRFg5/Peft+QokoQ2DT05 l6NDJmvgmFSXBvKr0RWxYQMwhARawYJ9/ujJaZ/evlQfaQsE/CidazBejhqj70rY9gUD XlIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=qsV0eVjKYB5Ht9c59OfB9Sm/LmewaWxhknqAxfD2Qm8=; b=XYqnmkjdfHMt/kkE3Imw86+E9WYCrA4qoFTjkNCIPwKxMdm7H/WbXC41eSkUnJ0oG1 nOLO+3X+qGG6H63KuSax022zCoHxE6I61J6mlS19qo2D/+HFNiFW9wev3eJoetj/I4IX 3k3ipJPk/S37Dvimsi9jAhkTwg06ql9A50EcfvHEb/1hBdqH1vJVavLd3MJ2QXQY1CA+ uPP4AejQaGlHoRjnD2gJUGGoJg8SmR95G+iIj56YNf0WPYgnAvFEPBc/C6+t74bRqc+x ArPRRlNcZBFfCQLOsr07Loazxx8ZilGI9GwyhGDfd7ryY1PBVdFE0qA1bD4GGBngq0Jq mPmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Zxmbug83; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id w203sor3830217itb.21.2018.11.26.16.03.13 for (Google Transport Security); Mon, 26 Nov 2018 16:03:13 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a24:ee83:: with SMTP id b125mr26694911iti.151.1543276992475; Mon, 26 Nov 2018 16:03:12 -0800 (PST) In-Reply-To: <55f4ba50-6b86-4f65-858a-754c347cdeb9@isocpp.org> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Zxmbug83; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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:41088 Archived-At: --000000000000ed395d057b9a2ca5 Content-Type: text/plain; charset="UTF-8" > > Seems like an XY problem to me. For the struct S, this is not a problem because it only has a singular > return type. But in more complicated pieces of code where proxies and > return type polymorphism lets you convert to multiple things (or you pick a > templated operator to cover all of the use cases), you have to do one of > Three > things: > > - Always convert to (int) and if it happens to fall outside of that, pray > the `static_cast` or c-style cast you applied does the right thing > - Incur a performance hit when someone asks for an integer and do bounds > checking on the value of the double to ensure it is, indeed, an integer > - Fix your types. 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). If a type doesn't have the semantic meaning you want it to (e.g. If a double allows more than just integers, but in this case you don't want it to) you still get exactly the same functionality by offering a type that wraps a double. 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. double operator int() seems, to me, to be the first step in a long line of potential bugs, code smells and baffled users. If they cast to double, expect a double. If they cast to int, expect an int. If they want to cast to an elephant expect an elephant, and so on. If they want an elephant masquerading as a giraffe, they can use our type interface to define a giraffe-like struct with an underlying elephant member and some checks that will get removed by virtue of contracts (and by C++20, compilers should be smart enough to reason about contracts sufficiently to give this zero runtime overhead if your function provably returns an integer double). This is, in fact, exactly how sol2 handles it: > https://github.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83 > > It would be better if, when being asked for an integer, the library author > could return a double and let the warning pop up for the user. > 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. Now, instead of the library picking for them or adding several different > macro-based > or type-based modes to handle various different kinds of states and potential errors (or > not), the user now loudly given a warning about a lossy conversion (on, for > example, VC++) and they can now make an informed decision about what they > want without requiring the library author to engage in obscene, unreadable > and hard-to-understand SFINAE for what is a very simple task: > https://github.com/ThePhD/sol2/blob/develop/sol/proxy_base.hpp#L41 > Sfinae is an inelegant sledgehammer in these situations, true. But is that a symptom of a problem in the language? I'm not convinced. As I stated in the paper, there is no confusion about the selection the > compiler selects the overload that is most appropriate based on the type > argument (e.g., when picking a constructor as in > http://eel.is/c++draft/class.conv#ctor). This is no different from today: > the return type never factors into the selection of such a function (and > never factors into regular overload resolution either). > I agree that there needs to be *some* solution, but T operator S() makes no sense to me (to the point of contradiction), and I'm sure that it will make no sense to average Joe. If it matches perfectly, that is fine (and you wouldn't be using the > extension). If it is something that is only convertible and requires a > constructor call, that is fine. If it is an error, that is also fine: now > the library is not in charge of making an executive decision of hiding what > could very well be a logic error on the part of the user (as demonstrated > with the case of working with an internal system). > Better typing does that for you anyway, by the same token. It also gives you the power to do more than allow a specific conversion, and to do more than avoid unnecessary conversion. It gives you control over more meaning than just the binary representation. -- 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/CAC%2B0CCOK1Nqi1W%3DeBcN7D1rrhiQ%2BCCp%2B8mkQNxjZp%3DXDv-i-DQ%40mail.gmail.com. --000000000000ed395d057b9a2ca5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like an XY problem to me.

For the struct S, this is not a problem= because it only has a singular return type. But in more complicated pieces= of code where proxies and return type polymorphism lets you convert to mul= tiple things (or you pick a templated operator to cover all of the use case= s), you have to do one of
Three
things:

- Always convert to = (int) and if it happens to fall outside of that, pray the `static_cast` or = c-style cast you applied does the right thing
- Incur a performance hit when someone asks f= or an integer and do bounds checking on the value of the double to ensure i= t is, indeed, an integer
- Fix your types.

If a language/library has a type that is represented in som= e form, then offer a conversion to that type, rather than masquerading it a= s another type that it is not. Or, more appropriately, give them a=C2=A0= strong=C2=A0type 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 do= n't care who thinks otherwise - 2.0 will never be an integer). If a typ= e doesn't have the semantic meaning you want it to (e.g. If a double al= lows more than just integers, but in this case you don't want it to) yo= u still get exactly the same functionality by offering a type that wraps a = double.

<= div dir=3D"auto" style=3D"font-family:sans-serif">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 t= hat wraps a rectangle, casts to a rectangle and a square (the latter requir= ing an actual conversion, the former just returning the rectangle held with= in), clearly identifies itself as a square rectangle, and there's no co= ntroversy.

double operator int() = seems, to me, to be the first step in a long line of potential bugs, code s= mells and baffled users. If they cast to double, expect a double. If they c= ast to int, expect an int. If they want to cast to an elephant expect an el= ephant, and so on. If they want an elephant masquerading as a giraffe, they= can use our type interface to define a giraffe-like struct with an underly= ing elephant member and some checks that will get removed by virtue of cont= racts (and by C++20, compilers should be smart enough to reason about contr= acts sufficiently to give this zero runtime overhead if your function prova= bly returns an integer double).

This is, in fact, exactly how sol2 handles it: https://githu= b.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83<= /div>

It would be better if, when being asked for an int= eger, the library author could return a double and let the warning pop up f= or the user.

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

Now, instead of the library picking for them or adding sever= al different macro-based

or type-based

<= /div>
modes to handle various different kinds of stat= es and potential errors (or not), the user now loudly given a warning about= a lossy conversion (on, for example, VC++) and they can now make an inform= ed decision about what they want without requiring the library author to en= gage in obscene, unreadable and hard-to-understand SFINAE for what is a ver= y simple task: https://= github.com/ThePhD/sol2/blob/develop/sol/proxy_base.hpp#L41

Sfinae is an inelegant sledgehammer in these situations, true. But is= that a symptom of a problem in the language? I'm not convinced.
<= div dir=3D"auto">
As I stated in the paper,= there is no confusion about the selection the compiler selects the overloa= d that is most appropriate based on the type argument (e.g., when picking a= constructor as in http://eel.is/c++draft/class.c= onv#ctor). This is no different from today: the return type never facto= rs into the selection of such a function (and never factors into regular ov= erload resolution either).


I agree t= hat there needs to be some solution, but T operator S() makes no sen= se to me (to the point of contradiction), and I'm sure that it will mak= e no sense to average Joe.

If it matches perfectly, that is fine (and you wouldn't be usi= ng the extension). If it is something that is only convertible and requires= a constructor call, that is fine. If it is an error, that is also fine: no= w the library is not in charge of making an executive decision of hiding wh= at could very well be a logic error on the part of the user (as demonstrate= d with the case of working with an internal system).

Better typi= ng does that for you anyway, by the same token. It also gives you the power= to do more than allow a specific conversion, and to do more than avoid unn= ecessary conversion. It gives you control over more meaning than just the b= inary representation.

--
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/CAC%2B0= CCOK1Nqi1W%3DeBcN7D1rrhiQ%2BCCp%2B8mkQNxjZp%3DXDv-i-DQ%40mail.gmail.com= ..
--000000000000ed395d057b9a2ca5-- .