Topic: Categorically qualified classes, first draft
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Sep 2014 19:16:07 +0800
Raw View
--Apple-Mail=_DC34943E-8C9F-4F49-841D-98AB1937432F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
I've finally just finished drafting my first (most ambitious) proposal for =
Urbana.
---
Some classes only work in certain contexts: scope guards are usually useles=
s as subexpressions, and expression template placeholders malfunction as lo=
cal variables. An unused function result may signal that the user intends t=
o follow a different protocol, such as with std::async. This proposal exten=
ds class definitions to prevent such errors, and adds a mechanism to automa=
tically resolve them by type substitution, such as a value type for an expr=
ession template. Additionally, generation of non-movable objects becomes mo=
re tractable.
The added functionality includes that of the "auto evaluation" proposals. T=
his proposal intends to be more expressive, more broadly applicable, and ea=
sier to adopt and use.
---
https://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=3D0
Share and enjoy. Or just fire away. But let me know what you think!
--=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=_DC34943E-8C9F-4F49-841D-98AB1937432F
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"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;"><div>I’ve fi=
nally just finished drafting my first (most ambitious) proposal for Urbana.=
</div><div><br></div><div>–––</div><div>Some classes only=
work in certain contexts: scope guards are usually useless as subexpressio=
ns, and expression template placeholders malfunction as local variable=
s. An unused function result may signal that the user intends to follo=
w a different protocol, such as with std::async. This proposal ex=
tends class definitions to prevent such errors, and adds a mechanism to aut=
omatically resolve them by type substitution, such as a value type for an&n=
bsp;expression template. Additionally, generation of non-movable objects be=
comes more tractable.</div><div><br></div><div>The added functionality incl=
udes that of the “auto evaluation” proposals. This proposa=
l intends to be more expressive, more broadly applicable, and easier t=
o adopt and use.<br>–––</div><div><br></div><a href=3D"ht=
tps://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=3D0">htt=
ps://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=3D0</a><d=
iv><br></div><div>Share and enjoy. Or just fire away. But let me know what =
you think!</div><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=_DC34943E-8C9F-4F49-841D-98AB1937432F--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Sat, 13 Sep 2014 14:51:28 -0700 (PDT)
Raw View
------=_Part_604_277821654.1410645088266
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I like this. What about functions that construct a value of a type with a &=
=20
qualifier, though? e.g.
template <typename T>
struct unique_lock & { ... }; // lvalue-only type definition
template <typename T>
auto make_lock(T& mutex)
{
unique_lock<T> lock(mutex);
// ... stuff
return lock;
}
void foo()
{
std::mutex some_mutex;
{
auto lock =3D make_lock(some_mutex);
// ... stuff
}
}
? If I recall correctly (I probably don't) there were some use cases for=20
constructs similar to that I saw in a CppCon talk (I don't recall which).
On Thursday, September 11, 2014 4:16:46 AM UTC-7, David Krauss wrote:
>
> I=E2=80=99ve finally just finished drafting my first (most ambitious) pro=
posal for=20
> Urbana.
>
> =E2=80=93=E2=80=93=E2=80=93
> Some classes only work in certain contexts: scope guards are usually=20
> useless as subexpressions, and expression template placeholders malfuncti=
on=20
> as local variables. An unused function result may signal that the=20
> user intends to follow a different protocol, such as with std::async. Thi=
s=20
> proposal extends class definitions to prevent such errors, and adds a=20
> mechanism to automatically resolve them by type substitution, such as a=
=20
> value type for an expression template. Additionally, generation of=20
> non-movable objects becomes more tractable.
>
> The added functionality includes that of the =E2=80=9Cauto evaluation=E2=
=80=9D proposals.=20
> This proposal intends to be more expressive, more broadly applicable,=20
> and easier to adopt and use.
> =E2=80=93=E2=80=93=E2=80=93
>
> https://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=3D0
>
> Share and enjoy. Or just fire away. But let me know what you think!
>
>
--=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/.
------=_Part_604_277821654.1410645088266
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I like this. What about functions that construct a value o=
f a type with a & qualifier, though? e.g.<div><br></div><div>&nbs=
p; template <typename T></div><div> struct unique_lock & { =
.... }; // lvalue-only type definition</div><div><br></div><div> templ=
ate <typename T></div><div> auto make_lock(T& mutex)</div><=
div> {</div><div> unique_lock<T> lock(mutex);</div=
><div> // ... stuff</div><div> return lock;</div>=
<div> }</div><div><br></div><div> void foo()</div><div> {=
</div><div> std::mutex some_mutex;</div><div> {</=
div><div> auto lock =3D make_lock(some_mutex);<br></div=
><div> // ... stuff</div><div> }</div><div=
> }</div><div><br></div><div>? If I recall correctly (I probably don'=
t) there were some use cases for constructs similar to that I saw in a CppC=
on talk (I don't recall which).</div><div><br>On Thursday, September 11, 20=
14 4:16:46 AM UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div style=3D"word-wrap:break-word"><div>I=E2=80=99ve finally jus=
t finished drafting my first (most ambitious) proposal for Urbana.</div><di=
v><br></div><div>=E2=80=93=E2=80=93=E2=80=93</div><div>Some classes only wo=
rk in certain contexts: scope guards are usually useless as subexpressions,=
and expression template placeholders malfunction as local variables. =
An unused function result may signal that the user intends to follow a=
different protocol, such as with std::async. This proposal exten=
ds class definitions to prevent such errors, and adds a mechanism to automa=
tically resolve them by type substitution, such as a value type for an =
;expression template. Additionally, generation of non-movable objects becom=
es more tractable.</div><div><br></div><div>The added functionality include=
s that of the =E2=80=9Cauto evaluation=E2=80=9D proposals. This propos=
al intends to be more expressive, more broadly applicable, and easier =
to adopt and use.<br>=E2=80=93=E2=80=93=E2=80=93</div><div><br></div><a hre=
f=3D"https://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=
=3D0" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fkyazozoftdmj21u%2FClass-qualifi=
cation.pdf%3Fdl%3D0\46sa\75D\46sntz\0751\46usg\75AFQjCNH3-rBWChVAGMdVrsQohK=
uz4UVN9g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?=
q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fkyazozoftdmj21u%2FClass-qualificati=
on.pdf%3Fdl%3D0\46sa\75D\46sntz\0751\46usg\75AFQjCNH3-rBWChVAGMdVrsQohKuz4U=
VN9g';return true;">https://www.dropbox.com/s/<wbr>kyazozoftdmj21u/Class-<w=
br>qualification.pdf?dl=3D0</a><div><br></div><div>Share and enjoy. Or just=
fire away. But let me know what you think!</div><div><br></div></div></blo=
ckquote></div></div>
<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 />
------=_Part_604_277821654.1410645088266--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 14 Sep 2014 06:47:53 +0800
Raw View
On 2014-09-14, at 5:51 AM, Sean Middleditch <sean.middleditch@gmail.com> wr=
ote:
> I like this. What about functions that construct a value of a type with a=
& qualifier, though? =20
Yes, factory functions.
Temporaries are allowed for & (lvalue) qualified types, but only for the pu=
rpose of initializing something else.
From the proposal =A72:
> A sole prvalue initializer of an object is exempt from this constraint. T=
his includes function arguments passed by value, constructor calls with one=
argument passed by value or by reference, and full-expressions in return s=
tatements.
=A73.1:
> Classes that otherwise cannot form temporaries are allowed to do so to in=
itialize other objects. This is in the expectation that the temporary will =
be converted with move semantics, and after the conversion the temporary wi=
ll be moved-from, empty, and inconsequential. It is also necessary to suppo=
rt copy-initialization, which is a popular way to initialize persistent obj=
ects.
Perhaps this should be clarified a bit more; the first paragraph there is a=
bit dense.
I've updated the working copy with clearer emphasis:
This constraint is not applied to an expression which initializes an object=
; an lvalue qualified class may form temporaries for such a purpose. This i=
ncludes ...
Thanks!
--=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/.
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Sat, 13 Sep 2014 16:04:15 -0700
Raw View
Great! I admit my brain has trouble reading standardese like this so
it might well have been totally clear to a smarter person than I. :)
On Sat, Sep 13, 2014 at 3:47 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-09-14, at 5:51 AM, Sean Middleditch <sean.middleditch@gmail.com> =
wrote:
>
>> I like this. What about functions that construct a value of a type with =
a & qualifier, though?
>
> Yes, factory functions.
>
> Temporaries are allowed for & (lvalue) qualified types, but only for the =
purpose of initializing something else.
>
> From the proposal =C2=A72:
>> A sole prvalue initializer of an object is exempt from this constraint. =
This includes function arguments passed by value, constructor calls with on=
e argument passed by value or by reference, and full-expressions in return =
statements.
>
> =C2=A73.1:
>> Classes that otherwise cannot form temporaries are allowed to do so to i=
nitialize other objects. This is in the expectation that the temporary will=
be converted with move semantics, and after the conversion the temporary w=
ill be moved-from, empty, and inconsequential. It is also necessary to supp=
ort copy-initialization, which is a popular way to initialize persistent ob=
jects.
>
> Perhaps this should be clarified a bit more; the first paragraph there is=
a bit dense.
>
> I've updated the working copy with clearer emphasis:
>
> This constraint is not applied to an expression which initializes an obje=
ct; an lvalue qualified class may form temporaries for such a purpose. This=
includes ...
>
> Thanks!
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/8gHf_-egmk0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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-propo=
sals/.
--=20
Sean Middleditch
http://seanmiddleditch.com
--=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/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Sun, 14 Sep 2014 19:38:46 +0200
Raw View
--047d7b33d0048a765e050309fdda
Content-Type: text/plain; charset=UTF-8
The & and && syntax in the class name is short, but might be harder to
search for than some contextual keywords.
Otherwise, this is very interesting. I'm particularly interested in fixing
the two-step intialization problem.
--
---
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/.
--047d7b33d0048a765e050309fdda
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">The & and && syntax=
in the class name is short, but might be harder to search for than some co=
ntextual keywords.=C2=A0</div><div class=3D"gmail_extra">Otherwise, this is=
very interesting. I'm particularly interested in fixing the two-step i=
ntialization problem.<br></div><div class=3D"gmail_extra"><br></div></div>
<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 />
--047d7b33d0048a765e050309fdda--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 14 Sep 2014 20:58:46 +0300
Raw View
On 14 September 2014 20:38, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> w=
rote:
> The & and && syntax in the class name is short, but might be harder to
> search for than some contextual keywords.
> Otherwise, this is very interesting. I'm particularly interested in fixin=
g
> the two-step intialization problem.
I wonder whether we should qualify individual constructors instead of
(or in addition to)
the class. Chances are that designs will emerge where it's fine to construc=
t a
temporary in some cases, but not in others, depending on the source of
the construction.
For example, I might want to say that an object of my class can be a
temporary if it
was constructed from an lvalue, but may not be a temporary if it was
constructed from
an rvalue.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 15 Sep 2014 07:31:37 +0800
Raw View
--Apple-Mail=_B5BF11FA-4C55-4362-AB49-C0034530FABF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-15, at 1:58 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> I wonder whether we should qualify individual constructors instead of
> (or in addition to)
> the class.
This is mentioned in section 3.4.
> Chances are that designs will emerge where it's fine to construct a
> temporary in some cases, but not in others, depending on the source of
> the construction.
> For example, I might want to say that an object of my class can be a
> temporary if it
> was constructed from an lvalue, but may not be a temporary if it was
> constructed from
> an rvalue.
That's essentially true of classes that retain an internal reference:
Expression templates must be rvalues because of internal references to temp=
oraries. If you provided persistent operands, then the ET object could pers=
ist. (Well, you'd also have to contend with destructive evaluation.)
Reference wrappers must be constructed from lvalues, because they are not g=
uaranteed to be temporary.
Usually, template specializations are constructed by factory functions (in =
these cases, operator overloads or std::ref) and that would be the point of=
discrimination to decide between types of differing qualification.
So, a user could add this overload to std::ref (in their own namespace, I j=
ust used std:: habitually):
template< typename referent >
struct temp_reference_wrapper &&
: std::reference_wrapper< referent > {
temp_reference_wrapper( referent && r )
: std::reference_wrapper< referent >( r ) {}
temp_reference_wrapper( referent & ) =3D delete; // Use reference_wrapp=
er for persistent objects.
// Interface is the same.
};
template< typename referent >
std::enable_if_t< ! is_reference_v< referent >,
temp_reference_wrapper < referent > >
ref( referent && r )
{ return std::move( referent ); }
Perhaps it would be nice to have conditional qualification:
template< typename T >
class foo && (bears_temp_reference< T >)
{};
I think that can be added subsequently, if necessary. Following your sugges=
tion, it would be more useful in combination with deduction of class templa=
te parameters from constructor arguments. (If constructors are allowed to d=
ecide a little about the enclosing class template, they should be allowed t=
o decide a lot.)
--=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=_B5BF11FA-4C55-4362-AB49-C0034530FABF
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;"><br><div><div>On 2014&=
ndash;09–15, at 1:58 AM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">I wonder wh=
ether we should qualify individual constructors instead of<br>(or in additi=
on to)<br>the class. </blockquote><div><br></div><div>This is mentioned in =
section 3.4.</div><div><br></div><blockquote type=3D"cite">Chances are that=
designs will emerge where it's fine to construct a<br>temporary in some ca=
ses, but not in others, depending on the source of<br>the construction.<br>=
For example, I might want to say that an object of my class can be a<br>tem=
porary if it<br>was constructed from an lvalue, but may not be a temporary =
if it was<br>constructed from<br>an rvalue.<br></blockquote><div><br></div>=
<div>That’s essentially true of classes that retain an internal refer=
ence:</div><div><br></div><div>Expression templates must be rvalues because=
of internal references to temporaries. If you provided persistent operands=
, then the ET object could persist. (Well, you’d also have to contend=
with destructive evaluation.)</div><div><br></div><div>Reference wrappers =
must be constructed from lvalues, because they are not guaranteed to be tem=
porary.</div></div><br><div>Usually, template specializations are construct=
ed by factory functions (in these cases, operator overloads or <font face=
=3D"Courier">std::ref</font>) and that would be the point of discrimination=
to decide between types of differing qualification.</div><div><br></div><d=
iv>So, a user could add this overload to <font face=3D"Courier">std::ref</f=
ont> (in their own namespace, I just used <font face=3D"Courier">std::=
</font> habitually):</div><div><br></div><div><div><font face=3D"Courier">t=
emplate< typename referent ></font></div></div><div><font face=3D"Cou=
rier">struct temp_reference_wrapper &&</font></div><div><font face=
=3D"Courier"> : std::reference_wrapper< referent > {</fo=
nt></div><div><font face=3D"Courier"> </font><span style=
=3D"font-family: Courier;">temp_reference_wrapper</span><font face=3D"Couri=
er">( referent && r )</font></div><div><font face=3D"Courier"> =
; : std::reference_wrapper< referent >( r ) {}</=
font></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"=
Courier"> temp_reference_wrapper( referent & ) =3D delete;=
// Use reference_wrapper for persistent objects.</font></div><div><fo=
nt face=3D"Courier"><br></font></div><div><font face=3D"Courier"> &nb=
sp; // Interface is the same.</font></div><div><font face=3D"Courier">};</f=
ont></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"C=
ourier">template< typename referent ></font></div><div><font face=3D"=
Courier">std::enable_if_t< ! is_reference_v< referent >,</font></d=
iv><div><span style=3D"font-family: Courier;">temp_reference_wrapper</span>=
<font face=3D"Courier">< referent > ></font></div><div><font=
face=3D"Courier">ref( referent && r )</font></div><div><font face=
=3D"Courier"> { return std::move( referent ); }</font></div><d=
iv><br></div><div>Perhaps it would be nice to have conditional qualificatio=
n:</div><div><br></div><div><font face=3D"Courier">template< typename T =
></font></div><div><font face=3D"Courier">class foo && (bears_te=
mp_reference< T >)</font></div><div><font face=3D"Courier"> &nb=
sp; {};</font></div><div><br></div><div>I think that can be added subsequen=
tly, if necessary. Following your suggestion, it would be more useful in co=
mbination with deduction of class template parameters from constructor argu=
ments. (If constructors are allowed to decide a little about the enclosing =
class template, they should be allowed to decide a lot.)</div><div><br></di=
v></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=_B5BF11FA-4C55-4362-AB49-C0034530FABF--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 08 Oct 2014 17:30:13 -0400
Raw View
On 2014-09-11 07:16, David Krauss wrote:
> I've finally just finished drafting my first (most ambitious) proposal fo=
r Urbana.
>=20
> ---
> Some classes only work in certain contexts: scope guards are usually usel=
ess as subexpressions, and expression template placeholders malfunction as =
local variables. An unused function result may signal that the user intends=
to follow a different protocol, such as with std::async. This proposal ext=
ends class definitions to prevent such errors, and adds a mechanism to auto=
matically resolve them by type substitution, such as a value type for an ex=
pression template. Additionally, generation of non-movable objects becomes =
more tractable.
>=20
> The added functionality includes that of the "auto evaluation" proposals.=
This proposal intends to be more expressive, more broadly applicable, and =
easier to adopt and use.
> ---
>=20
> https://www.dropbox.com/s/kyazozoftdmj21u/Class-qualification.pdf?dl=3D0
Editorial: 4.1 seems to be missing a '{' after the class name?
Bikeshed: 'class && name'?
It seems like it would be useful to use these qualifiers on template
parameters also, e.g. 'template <typename & T>'. Is that permitted and I
missed it (I mostly skimmed)? Have you considered it for a follow-up
proposal? Am I wrong and it would be useless or otherwise a bad idea?
This makes me want 'using(foo) {...}' again :-).
--=20
Matthew
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 9 Oct 2014 11:51:52 +0800
Raw View
On 2014-10-09, at 5:30 AM, Matthew Woehlke <mw_triad@users.sourceforge.net>=
wrote:
> Editorial: 4.1 seems to be missing a '{' after the class name?
Yes :(
It's submitted and distributed already. I've been submitting papers early t=
o avoid submitting a very large number at the last minute.
I do proofread everything, and most gets checked twice, honest.
> Bikeshed: 'class && name'?
Then the class definition syntax wouldn't match elaborated-type-specifier, =
which is the forward declaration syntax.
I don't think there's much wiggle room.
> It seems like it would be useful to use these qualifiers on template
> parameters also, e.g. 'template <typename & T>'. Is that permitted and I
> missed it (I mostly skimmed)? Have you considered it for a follow-up
> proposal? Am I wrong and it would be useless or otherwise a bad idea?
I think it would be useless. There is never a need to require that a templa=
te argument cannot be used for a particular purpose. You can guarantee that=
a template's use of an argument satisfies a qualifier by testing it with a=
qualified class. An unqualified class could have implicit conversions that=
would be triggered unexpectedly by adding a qualifier so naively. Class qu=
alifiers looks like reference qualifiers but they combine differently.
If you really want to, you can add a qualifier to a class by deriving from =
it with inheriting constructors, but I wouldn't recommend that for anything=
generic.
--=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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 09 Oct 2014 13:53:48 -0400
Raw View
On 2014-10-08 23:51, David Krauss wrote:
> On 2014-10-09, at 5:30 AM, Matthew Woehlke wrote:
>> It seems like it would be useful to use these qualifiers on template
>> parameters also, e.g. 'template <typename & T>'. Is that permitted and I
>> missed it (I mostly skimmed)? Have you considered it for a follow-up
>> proposal? Am I wrong and it would be useless or otherwise a bad idea?
>
> I think it would be useless. There is never a need to require that a
> template argument cannot be used for a particular purpose. You can
> guarantee that a template's use of an argument satisfies a qualifier
> by testing it with a qualified class. An unqualified class could have
> implicit conversions that would be triggered unexpectedly by adding a
> qualifier so naively. Class qualifiers looks like reference
> qualifiers but they combine differently.
I guess I'm not convinced that this would never make sense. OTOH, will
it be possible to do an enable_if based on a type being non-temporary or
non-persistent?
Anyway, this seems like it can and maybe should wait for a concrete use
case. I was mostly curious if it was something you'd thought about it.
Thanks,
--
Matthew
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 10 Oct 2014 06:36:01 +0800
Raw View
--Apple-Mail=_4B026C1F-FE1D-4A00-9D6D-2FF1E63D40D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-10, at 1:53 AM, Matthew Woehlke <mw_triad@users.sourceforge.net>=
wrote:
> OTOH, will
> it be possible to do an enable_if based on a type being non-temporary or
> non-persistent?
See =A72.1. std::decay<T> is proposed to have a built-in enable_if< persist=
ent >, and std::as_temporary<T> (name to be bikeshedded, perhaps std::as_ex=
pression) will have a built-in enable_if< temporary >. You would have to co=
nstruct non-temporary or non-persistent conditions from those. Negating an =
enable_if requires a new metafunction.
Time and experience should tell us if more metafunctions are needed than al=
ready proposed. I'm trying to keep them down to a minimum.
--=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=_4B026C1F-FE1D-4A00-9D6D-2FF1E63D40D3
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;"><br><div><div>On 2014&=
ndash;10–10, at 1:53 AM, Matthew Woehlke <<a href=3D"mailto:mw_tri=
ad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</di=
v><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px; float: none; display: inline !important;">OTOH, will</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;"><span style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inlin=
e !important;">it be possible to do an enable_if based on a type being non-=
temporary or</span><br style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;"><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;">non-persistent?</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;"></blockquote></div><div><br></div>See =A72.1. <font face=3D"Courier=
">std::decay<T></font> is proposed to have a built-in <font face=3D"C=
ourier">enable_if< persistent ></font>, and <font face=3D"Courier">st=
d::as_temporary<T></font> (name to be bikeshedded, perhaps <font face=
=3D"Courier">std::as_expression</font>) will have a built-in <font face=3D"=
Courier">enable_if< temporary ></font>. You would have to construct n=
on-temporary or non-persistent conditions from those. Negating an <font fac=
e=3D"Courier">enable_if</font> requires a new metafunction.<div><br></div><=
div>Time and experience should tell us if more metafunctions are needed tha=
n already proposed. I’m trying to keep them down to a minimum.</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=_4B026C1F-FE1D-4A00-9D6D-2FF1E63D40D3--
.