Topic: Strong typedefs as a basis for contracts and
Author: David Krauss <potswa@gmail.com>
Date: Wed, 9 Jul 2014 17:44:23 +0800
Raw View
--Apple-Mail=_D118E627-43F4-45A2-AE64-AE013B3A362B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
N3741 says,
> Pointers/references to an opaque type are to be explicitly convertible, v=
ia a type adjustment, to pointers/references to the underlying type, and co=
nversely. This may imply that an underlying type should be considered refer=
ence-related to its opaque type
An opaque typedef declaration would seem to be an ideal means to add extens=
ion methods, without corrupting a class' original interface, adding potenti=
al collisions etc. The user defines a new interface, declaring whether or n=
ot to inherit the entire original interface. They obtain a new, completely =
distinct static type, which is completely ABI-compatible with the original =
type. (The dynamic type of the object cannot be changed this way.)
Likewise, the addition of "conversion constructor" and "conversion function=
" syntax to the proposed opaque-definition syntax could allow contracts to =
be checked at runtime, and then propagated through the type system. Such fu=
nctions could work with only const operands, and the user would need to min=
d the difference between casting values and casting references. This is jus=
t a kernel of an idea, maybe it needs more development.
Used in concert, the user could filter a class through an adapter interface=
, only as long as it satisfies some conditions, which are asserted implicit=
ly in debug builds. Move semantics (not by constructor, but only by opaque =
typedef no-op conversion) could express switching a single object between d=
ifferent interfaces that intend to be used mutually exclusively due to cont=
ract requirements.
Both of these applications would benefit from composability. It would be ni=
ce to define a class extension, or a contract, in terms of preexisting ones=
, a la multiple inheritance. Conversion (by value or reference binding) to =
a weaker contract or underlying class sub-extension would follow a similar =
pattern as the derived-to-base conversion, including ambiguity being ill-fo=
rmed.
Well... that's all I got. Just wanted to share before the idea gets paged i=
nto the bit-bucket of my mind. Examples are left as an exercise to the read=
er.
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_D118E627-43F4-45A2-AE64-AE013B3A362B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>N3741 says,</div>=
<div><br></div><blockquote type=3D"cite">Pointers/references to an opaque t=
ype are to be explicitly convertible, via a type adjustment, =
;to pointers/references to the underlying type,&nb=
sp;and conversely. This may imply that an&nbs=
p;underlying type should be considered reference-related to its o=
paque type</blockquote><div><br></div><div>An opaque typedef declaration wo=
uld seem to be an ideal means to add extension methods, without corrupting =
a class’ original interface, adding potential collisions etc. The use=
r defines a new interface, declaring whether or not to inherit the entire o=
riginal interface. They obtain a new, completely distinct static type, whic=
h is completely ABI-compatible with the original type. (The dynamic type of=
the object cannot be changed this way.)</div><div><br></div><div>Likewise,=
the addition of “conversion constructor” and “conversion=
function” syntax to the proposed <i>opaque-definition</i> syntax cou=
ld allow contracts to be checked at runtime, and then propagated through th=
e type system. Such functions could work with only <font face=3D"Courier">c=
onst</font> operands, and the user would need to mind the difference betwee=
n casting values and casting references. This is just a kernel of an idea, =
maybe it needs more development.</div><div><br></div><div>Used in concert, =
the user could filter a class through an adapter interface, only as long as=
it satisfies some conditions, which are asserted implicitly in debug build=
s. Move semantics (not by constructor, but only by opaque typedef no-op con=
version) could express switching a single object between different interfac=
es that intend to be used mutually exclusively due to contract requirements=
..</div><div><br></div><div>Both of these applications would benefit from co=
mposability. It would be nice to define a class extension, or a contract, i=
n terms of preexisting ones, a la multiple inheritance. Conversion (by valu=
e or reference binding) to a weaker contract or underlying class sub-extens=
ion would follow a similar pattern as the derived-to-base conversion, inclu=
ding ambiguity being ill-formed.</div><div><br></div><div>Well… that=
’s all I got. Just wanted to share before the idea gets paged into th=
e bit-bucket of my mind. Examples are left as an exercise to the reader.</d=
iv><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_D118E627-43F4-45A2-AE64-AE013B3A362B--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 9 Jul 2014 18:17:50 +0800
Raw View
On 2014-07-09, at 5:44 PM, David Krauss <potswa@gmail.com> wrote:
> Conversion (by value or reference binding) to a weaker contract or underlying class sub-extension would follow a similar pattern as the derived-to-base conversion, including ambiguity being ill-formed.
To clarify this point: inheritance of a particular underlying type via multiple paths would not produce ambiguity, since there's just one object, and if it's already inherited, its requirements must have been satisfied.
Ambiguity would only be between different function overloads accepting different underlying types, or implicit no-op conversions to different types.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.