Topic: d1193 (Unpublished) - Explicit Return Types
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 25 Nov 2018 22:09:00 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Also:</div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><=
div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate =
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial;=
background-color: rgb(255, 255, 255);">class X {</div><div style=3D"width:=
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"> IntProxy operator int ()=E2=80=8E { retur=
n IntProxy{17}; }</div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);">};</div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; =
font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-ser=
if; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255=
, 255, 255);">X x;</div><div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 1=
25); text-align: initial; background-color: rgb(255, 255, 255);">int y =3D =
x;</div><div style=3D"width: 100%; font-size: initial; font-family: Calibri=
, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align:=
initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);">I guess that also calls IntProxy -> int, which =
in turn could return AnotherIntProxy=E2=80=8E, ... etc.</div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;">Which makes sense, actually. But it means we could any number of convers=
ions, which is novel. Although it is like operator -> I guess.</div><div=
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro=
', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; ba=
ckground-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br =
style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans=
-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgroun=
d-color: rgb(255, 255, 255);">Sent from my BlackBerry p=
ortable Babbage Device</div> =
=
<table wi=
dth=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><=
tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; back=
ground-color: rgb(255, 255, 255);"> <div style=3D=
"border-style: solid none none; border-top-color: rgb(181, 196, 223); borde=
r-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans=
', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Balog Pal</div><div><=
b>Sent: </b>Sunday, November 25, 2018 7:57 PM</div><div><b>To: </b>ISO C++ =
Standard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp=
..org</div><div><b>Subject: </b>[std-proposals] Re: d1193 (Unpublished) - Ex=
plicit Return Types for (Implicit) Conversions</div></div></td></tr></tbody=
></table><div style=3D"border-style: solid none none; border-top-color: rgb=
(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: ini=
tial; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_original=
Content" style=3D""><div dir=3D"ltr"><div>Yes, provide examples of actual u=
se and some problem case that it actually solves.</div><div><br></div><div>=
The example you did write is more than confusing to think about. That opera=
tor triggers where context wants int and I provided S. So then what happens=
: operator int is invoked, it returns a double that is in turn converted to=
int. Wow. Why that there and back conversion is good?</div><div><br></div>=
<div>If the intent is to return some int_proxy instance, that has an operat=
or int itself, then it might make sense, but it is 2 user-defined conversio=
ns that would not work with current rules, how you intend to cover that wit=
hout impact on existing code?<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6d5ed13d-c31a-4218-88b0-e0dd4bef3f72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/6d5ed13d-c31a-4218-88b0-e0dd4bef=
3f72%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181126030900.5181497.67732.66720%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20181126030900.5181497.67732.66720%40gm=
ail.com</a>.<br />
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 27 Nov 2018 00:03:02 +0000
Raw View
--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
<div dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div></div></div></blockquote></div></d=
iv><div dir=3D"auto">Seems like an XY problem to me.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>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</div></div></blockquote></div></div><div dir=3D"a=
uto">Three</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div> things:<br><br>- 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</div></div></blockquote></div=
></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>- 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<br></div></div></blockquote></div></div><div dir=
=3D"auto">- Fix your types.</div><div dir=3D"auto"><div style=3D"font-famil=
y:sans-serif" dir=3D"auto"><div class=3D"m_-5081132507049233974elided-text"=
><div dir=3D"ltr"><br></div></div></div><div dir=3D"auto" style=3D"font-fam=
ily:sans-serif">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<b>=
strong</b>=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><div dir=3D"auto" style=3D"font-family:sans-serif"><br></div><=
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.</div><div dir=3D"auto" style=3D"font-family:sans-serif"><br></di=
v><div dir=3D"auto" style=3D"font-family:sans-serif">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).</div></div><div dir=3D"auto"><br></div><div=
dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>This is, in fact, exactly how sol2 handles it: <a href=
=3D"https://github.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unquali=
fied.hpp#L83" rel=3D"noreferrer noreferrer" target=3D"_blank">https://githu=
b.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83</a><=
/div><div><br></div><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.</div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>Now, instead of the library picking for them or adding sever=
al different macro-based </div></div></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">or type-based</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><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: <a href=3D"https://github.com/ThePhD/sol2/blob/develop/sol/p=
roxy_base.hpp#L41" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
github.com/ThePhD/sol2/blob/develop/sol/proxy_base.hpp#L41</a></div><div></=
div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">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><=
div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>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 <a href=3D"http://eel.is/c++draft/class.conv#ctor" rel=
=3D"noreferrer noreferrer" target=3D"_blank">http://eel.is/c++draft/class.c=
onv#ctor</a>). 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).<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I agree t=
hat there needs to be <i>some</i> 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.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div> 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).<br></div></div></block=
quote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOK1Nqi1W%3DeBcN7D1rrhiQ%2BCC=
p%2B8mkQNxjZp%3DXDv-i-DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0=
CCOK1Nqi1W%3DeBcN7D1rrhiQ%2BCCp%2B8mkQNxjZp%3DXDv-i-DQ%40mail.gmail.com</a>=
..<br />
--000000000000ed395d057b9a2ca5--
.
Author: The PhD <phdofthehouse@gmail.com>
Date: Mon, 26 Nov 2018 21:15:35 -0800 (PST)
Raw View
------=_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<int> 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<int>( 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
<div dir=3D"ltr">Richard Smith:<br>> 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.<br><div><br></div><div>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.<br><br>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 -- <a href=3D"https://twitter.com/hanka=
dusikova/status/1045470553069375488">https://twitter.com/hankadusikova/stat=
us/1045470553069375488</a>).<br></div><div><br>Jake Arkinstall:<br>> 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=A0<b>strong</b>=
=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)<br><br>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?<br></div><div><br>> 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.<br><br>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 <span style=3D"font-family: cour=
ier new, monospace;">x =3D 2</span>. If they have to get it out on the othe=
r side with <span style=3D"font-family: courier new, monospace;">sol::doubl=
e_wrapper<int> x =3D virtual_machine["x"];</span>,
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.<br></div><div><br></=
div><div>> 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.<br><br>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,<br><br></div><div style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ov=
erflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">function</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> f </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> value0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> =C2=A0f</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">double</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> value1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">4.5</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">string</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> value2 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> =C2=A0f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">"foo"</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span></div></code></div><div><br></div><div>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<br><br>> 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.<br><br>=
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 <a href=3D"=
https://thephd.github.io/vendor/future_cxx/papers/d1193.html#motivation-mut=
ual">https://thephd.github.io/vendor/future_cxx/papers/d1193.html#motivatio=
n-mutual</a>).
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.<br><br>The goal is to remove some restrictio=
ns to bring them in line with regular functions.<br><br></div><div><br></di=
v><div><h3 class=3D"iw"><span style=3D"font-family: arial, sans-serif;"><fo=
nt size=3D"2"><span class=3D"qu" role=3D"gridcell" tabindex=3D"-1"><span na=
me=3D"mihailnajdenov@gmail.com" data-hovercard-id=3D"mihailnajdenov@gmail.c=
om" class=3D"gD" data-hovercard-owner-id=3D"22">mihail:</span></span></font=
></span></h3></div><div>> Yeah, a simplified version of these examples i=
s what people expect to see in the paper.<br></div><div>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.<br><br>> 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?<br>=
<br>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).<br><br>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.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/947f5ce9-161f-4c16-b173-9b36476a137e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/947f5ce9-161f-4c16-b173-9b36476a137e=
%40isocpp.org</a>.<br />
------=_Part_1753_2046607187.1543295735760--
------=_Part_1752_122634472.1543295735759--
.
Author: Balog Pal <pasa@lib.hu>
Date: Tue, 27 Nov 2018 04:38:28 -0800 (PST)
Raw View
------=_Part_1725_2113299995.1543322308577
Content-Type: multipart/alternative;
boundary="----=_Part_1726_1380416762.1543322308578"
------=_Part_1726_1380416762.1543322308578
Content-Type: text/plain; charset="UTF-8"
Now I read the actual paper too (and it is really nice)... just as other
say, you absolutely need to start with a REAL LIFE problem that is PITA and
get solved by this proposal. You did cover the technical ground and I'm
sure you can iron out the nits like multiple conversion chain, but I'm
quite sure that the general reaction would be "yeah, it can be done but why
the ... should we bother".
C++ has many clients and adds features that serve the mass, not unicorns.
The resources are allocated accordingly.
--
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/f7e777e1-3662-48bc-a0f4-7cee7d599341%40isocpp.org.
------=_Part_1726_1380416762.1543322308578
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Now I read the actual paper too (and it is really nic=
e)... just as other say, you absolutely need to start with a REAL LIFE prob=
lem that is PITA and get solved by this proposal. You did cover the technic=
al ground and I'm sure you can iron out the nits like multiple conversi=
on chain, but I'm quite sure that the general reaction would be "y=
eah, it can be done but why the ... should we bother".=C2=A0=C2=A0 <br=
></div><div><br></div><div>C++ has many clients and adds features that serv=
e the mass, not unicorns. The resources are allocated accordingly. <br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f7e777e1-3662-48bc-a0f4-7cee7d599341%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7e777e1-3662-48bc-a0f4-7cee7d599341=
%40isocpp.org</a>.<br />
------=_Part_1726_1380416762.1543322308578--
------=_Part_1725_2113299995.1543322308577--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 27 Nov 2018 14:38:16 +0000
Raw View
--000000000000139d65057ba66777
Content-Type: text/plain; charset="UTF-8"
On Tue, 27 Nov 2018, 05:15 The PhD <phdofthehouse@gmail.com wrote:
> > 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<int> 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
<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
27 Nov 2018, 05:15 The PhD <<a href=3D"mailto:phdofthehouse@gmail.com">p=
hdofthehouse@gmail.com</a> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>> 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=A0<b>strong</b>=
=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)<br><br>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></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto"></div><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?</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>There are functions which pull and=20
integer </div></div></blockquote></div></div><div dir=3D"auto">(not an inte=
ger in the C++ sense)=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>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?<br></div></div></blockquote></div></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div></div><div><br>> 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.<br><br>Because such a=20
design imposes a knowledge burden on the user.</div></div></blockquote></di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto"></div><div dir=3D"aut=
o">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.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>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 <span style=3D"font-family:couri=
er new,monospace">x =3D 2</span>. If they have to get it out on the other s=
ide with <span style=3D"font-family:courier new,monospace">sol::double_wrap=
per<int> x =3D virtual_machine["x"];</span>,
then I've failed in my design to provide something that matches basic=
=20
expectation.</div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">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.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>"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.<br></div></div></blo=
ckquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">As is cha=
nging a language for the sake of a rough edge appearing between it and a di=
fferent language.</div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP%3D%2BYqWiZAMQu3ejOJ4-%2Bwy=
deUgS2ust-EB7WmMYUdD2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
P%3D%2BYqWiZAMQu3ejOJ4-%2BwydeUgS2ust-EB7WmMYUdD2A%40mail.gmail.com</a>.<br=
/>
--000000000000139d65057ba66777--
.