220 41091 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 14:38:16 +0000 Lines: 216 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> <947f5ce9-161f-4c16-b173-9b36476a137e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000139d65057ba66777" X-Trace: blaine.gmane.org 1543329385 8097 195.159.176.226 (27 Nov 2018 14:36:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 14:36:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBZFN6XPQKGQESC7J4YA@isocpp.org Tue Nov 27 15:36:21 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it1-f200.google.com ([209.85.166.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gReTL-0001zB-Lq for gclcip-std-proposals@m.gmane.org; Tue, 27 Nov 2018 15:36:19 +0100 Original-Received: by mail-it1-f200.google.com with SMTP id 123sf27086808itv.6 for ; Tue, 27 Nov 2018 06:38:30 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1543329510; cv=pass; d=google.com; s=arc-20160816; b=05JjZ9br4hUc1OqXJfuVRYMfW1w2z0MnstY6Bn4seupF7r77kLVpK3zjqbTsHdZQdF urwNsY7nBwRqIHNiHJV0IgHpGGwe8OKjyn5tiV0paVkO0kglO0HuwkzYNu1BFRBuXZnj IIBU+XJujnCqUeK7ZQw3W1d6vIEaRa9YMgQaBnYznE4Q6c9vFCh/CdvzqneX4mHwLA5s tj3G2oRgaBlHRKmxRZQiFM51hYtKjjQZ7cRVpNqJP694iU6CTa8xtM5Ma0GC3Jo5NzPH Fg3HBQUM9GSGFbHb79uts9VI4xGy3YIFukeqScjicxaugyrok5CT/Qpw8aoWl5ihE7qm DMww== 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=BF5iCrdf+1jo5qq+A/haoytUTZb3rk71EhAqzMYgcg0=; b=VshyLPLUswP+zBL33kFSwVQrQ9d8RWwqXhDB7Vw/dTsGNLtGRv4Ne6lGCskZRUCAU2 h8EzM7tSB/0d/3UiTxMdFFPtGWtL1xpl44MGtrVUfNDX6TKBUXBVNr4w6OPb9FaeWbYi jQL6UttmCPZBKrp9X1YHBa5t/VjiMCss+hRwnJ58MeK67Q6ye074ucxl5QKRfypRNc+o r7g2CygI+mol6j+ykq64rb8TNppIilC/IvhrIDRjnDQA34MBg1SbNcSOLxejIDYg2JmA zxgVTLeq1v02o0xr78LFcFf2XBI3Q92zckmmX2dkqmyIFmXA20xWvAjUQPGHCu17geyF GBPA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M0pBuEB4; 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=BF5iCrdf+1jo5qq+A/haoytUTZb3rk71EhAqzMYgcg0=; b=BaB5mwyABhQAoWzInAiJDGSHucDvsDfElPZXI2XIheRXsJaopjc6MVA02qLTbhImki Tga66tgmutxanRUwAoOblYQUcPCWnHqEFrEmTyYxXQNA75LxHeIchISqrYw4Gj4hlvrM v4H+e+xqmWj4wun2tu1q1H4TpL6wfUvAhdkVMmydDLOP57vyxiS8DfxvUSYzx5/9rEsv UtVTV05/ZpWYgqqF+VKNxcxNXSttvWkwg22O0URd9BWAyO5bvD8qTnSkiZfVz9/yacY2 22jmf9j0TfZ9iQXq0C+jHnr3qq4iS5JQvwvhMEHjSXddAwKrBlINrO/TEzTlfF28nv/8 4iJA== 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=BF5iCrdf+1jo5qq+A/haoytUTZb3rk71EhAqzMYgcg0=; b=FGrftBjiKlOpUX3KHE9pFjXeOxUikZxqpDigUT2+JKMaNiVPNCDpPQD07gYj7nvsEv 2QjEqKQd/qOrtAtqwVj8kcbLV99kgNZmHc4vPGaa6BwI8aqTsxC0Ez4M42ixX0iwlpqp +cNyLR0quyAAlxrF77lsp/WeYAifEW2gXtM2H+FKpwIA1b+yoatvc3vj52NU2i164XCQ iVw+82h5N77kNYR9lTsUmlZZMBRVgKKeYGchtPy8hsQWOcoAzk1N2aOCagWPUyMjK19A T4GZ3oxxaoYkgipZ1rkTIqgX1+KjJynIEr1gYhM++3szmoR2bKM0t6q8Qg/2frbU6WHs c6gg== X-Gm-Message-State: AA+aEWbZfYB5OQSpbY7p5FXWkAbXpMjhCvkJyuUUlcrkybKr9F/7QBsI DGvVo9GyyncdTJw64+VhzMXUyQ== X-Google-Smtp-Source: AFSGD/UCEizYQyi2sgiVzTk7fqNISS6SiH1DZ4q79Mi9KekQeiYK3YofrUVcWTP/eMqZO/IvKsdjag== X-Received: by 2002:a24:7381:: with SMTP id y123mr550522itb.32.1543329509931; Tue, 27 Nov 2018 06:38:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a02:74a:: with SMTP id f71-v6ls8670913jaf.2.gmail; Tue, 27 Nov 2018 06:38:28 -0800 (PST) X-Received: by 2002:a02:7b09:: with SMTP id q9mr29200524jac.39.1543329508318; Tue, 27 Nov 2018 06:38:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543329508; cv=none; d=google.com; s=arc-20160816; b=y1onnGaQElyt0htRsbqXFKxfheeQczFv779LsmPidVpfRWoQK6mvsu0+KEr4zVv/Fz h8B6XdTIUBW4g5WIo2sHHgfLLzgNTSFNgBjNVoSv/CE2awpx4bXh0h6Y+icxhNAzWi/x kZkNB9tMDuWN7CxZ62jO87n20ocH0W6xdZ+WInB2mYJII7QIZiiuan7pdWOpjy04hyUN aSYPiljmjH6h2mvObTB9NMomYx5a8PmbaECv99cF9XKHr2X2kA6w8dUTUrAy2ao52xD6 0SJ4/eijexPNcWfQa24ORRYabBzMhWHrTOk1T45VK9g/lmpioxrhzqhSrOgEE+cRhNCH Zrrw== 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=2sD0eTEexyH1HYknfAGRdYWY7oVZ/h/i2AIdMcKK4U8=; b=SqTHK8+bKeFt0W9TAc0opX1UE2RiR1SVoBlg3ICl6xtfbYvYTn1wKh6cLm9SNBlhZb 5XPFXBEnt0nor9Tgoytxg2wpLQvUgPWpm7Vy3iAheNQsokhERTzPwjFPmR2CdO9vEI0B b8+DmmdIYZyTTX8t+c0xrnieNsz6FSMFx+fS1sVNuTkF5LcLUQHzSFDK2Tg5eFeq3Swn zkXKwxSQTC3eBhgMFBSQ99xOKK5d/VZoF3h7l3cfMUUcR7oJTwac4sEThmovp+UDNNU3 NnAILeb15d8QFYbIvNLqxZMKHagEss0bpal0T+6GIg33rSE6nGm/+mxGCwajgdaFad9O c/Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M0pBuEB4; 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 j65sor7297840itj.0.2018.11.27.06.38.28 for (Google Transport Security); Tue, 27 Nov 2018 06:38:28 -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:2716:: with SMTP id g22mr25295178ita.40.1543329507678; Tue, 27 Nov 2018 06:38:27 -0800 (PST) In-Reply-To: <947f5ce9-161f-4c16-b173-9b36476a137e@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=M0pBuEB4; 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:41091 Archived-At: --000000000000139d65057ba66777 Content-Type: text/plain; charset="UTF-8" On Tue, 27 Nov 2018, 05:15 The PhD > 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. > Theyre entitled to disagree with me, but they'd still be wrong. 2.0 is not an integer. They may put a hat and moustache on it and call it an integer, but its still a double. A double returning from an integer cast is, semantically, nonsense, because the representation is neither faithful nor logical. It would possibly be justifiable if a double was an integer equipped with a rational (though this obviously isn't the true binary representation, and there are 64 bit integers that cannot be represented as a double without loss). You highlight that yourself below, where you use the catch "as long as the number does not exceed the 53 allowed bits". That is no trivial catch, and when we get to more complex types we might see it more. How does the language handle this? Or is there no assumption that the return types are equivalent? There are functions which pull and integer > (not an integer in the C++ sense) > 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? > I'm not saying disable that. I'm saying that, while the underlying representation is a double, the constraint to integral values means that double is certainly the wrong type. It might be the fundamental type, but why hardcode your code base in that manner? It's clearly causing problems. > > 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. > It needn't if they are using the right types. I don't understand why they would ever want a T returned from an S conversion. 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. > Agreed. But why call it an int in the first place? It isn't one, not to C++. This is what I want to understand. "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. > As is changing a language for the sake of a rough edge appearing between it and a different language. Perhaps this is my ignorance speaking because I don't work with Lua, but I work with C++ extensions for other languages. Conversion between types is a part of every day life at the interface, and the only workaround to this is to have a set of types in your C++ code, specific to the target language, such that only those types (no native types unless they are in common) exist at the interface. Because Lua has an int that isn't what we call an int, then why call it an int on the C++ side? That part makes zero sense to me. Your rebuttal will probably make my point redundant, but I would still like to understand it better. -- 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%2B0CCP%3D%2BYqWiZAMQu3ejOJ4-%2BwydeUgS2ust-EB7WmMYUdD2A%40mail.gmail.com. --000000000000139d65057ba66777 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, = 27 Nov 2018, 05:15 The PhD <p= hdofthehouse@gmail.com wrote:
<= div dir=3D"ltr">
> If a language/library has a type that is represen= ted 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.
<= div dir=3D"auto">
Theyre= entitled to disagree with me, but they'd still be wrong. 2.0 is not an= integer. They may put a hat and moustache on it and call it an integer, bu= t its still a double. A double returning from an integer cast is, semantica= lly, nonsense, because the representation is neither faithful nor logical. = It would possibly be justifiable if a double was an integer equipped with a= rational (though this obviously isn't the true binary representation, = and there are 64 bit integers that cannot be represented as a double withou= t loss). You highlight that yourself below, where you use the catch "a= s long as the number does not exceed the 53 allowed bits". That is no = trivial catch, and when we get to more complex types we might see it more. = How does the language handle this? Or is there no assumption that the retur= n types are equivalent?

=
=
There are functions which pull and=20 integer
(not an inte= ger in the C++ sense)=C2=A0
from Lua, so long a= s 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?

I'm not saying disable that. I'm = saying that, while the underlying representation is a double, the constrain= t to integral values means that double is certainly the wrong type. It migh= t be the fundamental type, but why hardcode your code base in that manner? = It's clearly causing problems.


> For example, say you have a rectangle t= hat'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.

It needn't if they are using the right types. I don't understand= why they would ever want a T returned from an S conversion.

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 other s= ide with sol::double_wrap= per<int> x =3D virtual_machine["x"];, then I've failed in my design to provide something that matches basic= =20 expectation.

Agreed. But why call it an int in the first place? It i= sn't one, not to C++. This is what I want to understand.

"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.

As is cha= nging a language for the sake of a rough edge appearing between it and a di= fferent language.

Perhap= s this is my ignorance speaking because I don't work with Lua, but I wo= rk with C++ extensions for other languages. Conversion between types is a p= art of every day life at the interface, and the only workaround to this is = to have a set of types in your C++ code, specific to the target language, s= uch that only those types (no native types unless they are in common) exist= at the interface. Because Lua has an int that isn't what we call an in= t, then why call it an int on the C++ side? That part makes zero sense to m= e. Your rebuttal will probably make my point redundant, but I would still l= ike to understand it better.

--
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%2B0CC= P%3D%2BYqWiZAMQu3ejOJ4-%2BwydeUgS2ust-EB7WmMYUdD2A%40mail.gmail.com. --000000000000139d65057ba66777-- .